Re: [DDL-ML] SRCP 0.8

[Matthias Trute <mtrute@web.de>]

Lang-Sebastian@t-online.de wrote:
> 
> > Aha, mit wenig Aufwand. Mach mal einen Vorschlag. Wir schauen es uns
> > dann an.
> 
> Einfachster Fall, so wie wir es in unserem Softwareengineering Projekt
> gelöst haben:
> 
> Für jede Anmeldung über einen Server -Port:
> 
> Client-> Server:
> 
> PASS <password>
> 
> Server-> Client: (im Falle das Passwort OK)
> PASS OK
> 
> sonst:
> PASS ERROR <errortext>

Zwei Dinge haben (mind.) den Ausschlag gegeben, eine Clientauthentifizierung
rauszulassen:
- Die Implementation von  _sicheren_ Verfahren ist ziemlich komplex und
  eigentlich nur mit ziemlichen Aufwand an externen Bibliotheken machbar.

- Die Verwaltung von Clients und deren Strukturierung mit Gruppen und Rollen
  (ein absolutes Muß für eine brauchbare Anwendung) ist ebenfalls ziemlich
  aufwendig (Definition von Rollen, Gruppen und deren Rechten auf den
verschiedenen
  Geräten). Zumal dies ja persistent verwaltet werden muß. 


Da es zudem wünschenswert ist, die Paßworte zentral zu pflegen steigt der
Aufwand
noch einmal (die alternative, das der SRCP Server dies übernimmt macht die Sache
auch nicht eben einfacher). Und: Die Konzepte von NIS/WindowsDomänen(aka AD) usw 
sind sich  zwar ähnlich aber bei nahem betrachtet doch sehr unterschiedlich. Da 
zudem dieser Teil des Protokolls für alle Implementationen ziemlich gleich ist, 
haben wir lange überlegt, was die eigentliche Voraussetzung dafür ist. Und sind 
bei den LOCKs gelandet. Damit kann eine übergeordnete Instanz ein Gerät für sich
reservieren. Damit haben wir gleichzeitig eine Anforderung an das XRCP 
gefunden: Userverwaltung in den unterschiedlichen Welten (Unter Linux
wird man wohl ein PAM System umsetzen, bei Windows eine NTDomäne (AD)
einplanen müssen. Kerberos ist auch gerne gesehen.. etc.pp.

Insofern: die Meßlatte für das Thema liegt hoch. Das soll Dich aber nicht
abschrecken, rechne mit Diskussionen, wenn Du eine tolle Idee hast, wird sie
genommen. Die Locks müssen nicht der Weisheit letzter Schluß bleiben.

> 
> Ich weiss, dass dieses Verfahren nicht sicher ist und ich weiss dass das
> Passwort
> im Klartext übertragen wird und , und, und ...
> 
> Aber, es ist zumindest eine kleine Hürde,so dass nicht jeder mit einem
> Telnet-Client

Sowas nenne ich gerne "Putzfrauenabwehr". Da wir aber an anderen Stellen im
Protokoll doch ein recht anspruchsvolles Niveau haben wollten, haben wir
eben darauf verzichtet, hier eine nur schwache Lösung zu schaffen. Eine
starke Lösung würde den Umfang des SRCP mind. verdoppeln. Der jetzt gefundene
Kompromiß ist da ausreichend: Wer lauscht, bekommt keine sachdienlichen
Hinweise. Und alle anderen können, wenn sie wollen. Sie müssen aber nicht.

> auf dem SRCP-Server rumpfuscht. Unser Prof. bestand auf diese
> Minimalsicherung,

Ist ja auch ok. Zusammen mit dem XRCP können ein paar iptables Regeln
den/die SRCP Server ausreichend absichern (der bekommt dann nur Connects
vom XRCP Server, alle anderen werden schon auf TCP/IP Ebene abgeblockt).
Anderes Systeme haben da ähnliche Möglichkeiten.

> damit die geplante Modellbahnanlage mit zugehörigem Server zumindest ein
> wenig
> vor Vandalen im lokalen Netz geschützt ist. (Der Server wird in einem
> lokalen Netz
> mit ein paar hundert anderen Rechnern stecken ...)

iptables und Co. (unter Linux) wären euer Freund. Das hat aber nichts
mehr mit SRCP zu tun. Analog lassen sich auch http oder ftp Server absichern.

Ahoi
Matthias

PS: ob die angedachten PIC's Kerberos können? Eher fraglich.

-- 
http://members.tripod.de/mtrute/