Sicherheit von SSH-Jails

[nyxus]

Moin all,

ich bin dabei einen Server für die Dateisynchronisation per Unison aufzusetzen. Dabei möchte ich natürlich nicht, dass User A an die Daten von User B kommt. Jetzt habe ich gesehen, das die aktuellen SSH-Server die User auch in ihre Home-Verzeichnisse einsperren können. Dazu habe ich ein paar Fragen:

1) Wie sicher ist diese Art des SSH-Chroot?
2) Gibt es da Unterschiede zwischen den Distributionen oder aber evtl. bei Linux vs BSD?
3) Ist das überhaupt der richtige Weg um mein Ziel zu erreichen?


Danke im Voraus und schönen 3. Advent, Karsten

[ddm3ve]

Ich denke mal, ein gut ausgeklügeltes gehärtetes Filesystem sollte genügen.
Soweit ich es erkennen kann, baut sshd chroot auf libpam_chroot auf.

Diese Form des Changeroot ist natürlich je nach Aufwand und Muse überwindbar.
Ob das Deine Anwender tun?
Von der Schwierigkeit betrachtet ist es genau so kompliziert von einem chroot aus zu brechen, wie als unprivilegierter User Rootrechte zu erlangen.
Für beides gibt es wohl geeignete Tools.

In den Griff bekommt man es wohl nur, wenn man auch den Kernel härtet um typische Angriffsmuster zu unterbinden.

*Tippfehler und die Mängel der Rechtschreibhilfe entfernt.

[daemotron]

Hallo Karsten,

der sshd verwendet den chroot()-syscall des Kernels. Wie ddm3ve schon geschrieben hat, gibt es Mittel und Wege, diesen zu überlisten (z. B. chdir()-syscall). Wurde der Kernel aber mit Grsecurity oder RSBAC gepatched, ist ein Ausbruch so gut wie ausgeschlossen, selbst wenn der Angreifer innerhalb des Jails root-Rechte erlangen sollte.

Da die chroot()-Implementierung des jeweiligen Betriebssystems genutzt wird, gibt es natürlich Unterschiede - bei den Linux-Distributionen in Sachen Kernelversion, Patchlevel und ggf. zusätzlich verwendeten Security Patches, und zu den BSDs natürlich auch. Wobei die chroot()-Mechanismen der BSD-Systeme tendenziell noch leichter einen Ausbruch ermöglichen; zumindest wurde dort nie auf Ausbruchsicherheit Wert gelegt, da BSD für's ausbruchsichere Einsperren von Prozessen andere Mechanismen mitbringt (z. B. Jails unter FreeBSD, systrace unter OpenBSD).

Zu Frage 3 kann ich nicht viel sagen, da ich Unison zu wenig dafür kenne. Aber wenn Deine User keine pöhsen H4x0rs sind, dann müsste normalerweise die "normale" Rechteverwaltung doch schon genügen, um unbefugte Zugriffe zu unterbinden. chroot() sehe ich eher als (Notfall-)Sandboxing-Werkzeug für Prozesse, deren Verhalten schlecht kontrolliert werden kann, und weniger als lart.

[nyxus]

Danke für euer Hinweise.
Die User (nein Tron, das darf man bei uns nicht ...) sind sicher keine pöhsen H4x0rs, aber ich wollte es gerne nicht nur mit den Berechtigungen lösen, für den Fall dass man sich dabei mal verhaut.
Ich werde jetzt mal schauen, ob der Aufwand das System mit GRSecurity aufzusetzen vertretbar ist.
Weiterhin würde ich gerne einschränken, welche Befehle der Benutzer überhaupt aufrufen darf. Ist Authprog dafür noch das Tool der Wahl, oder kann man sowas inzwischen evtl. direkt im SSH-Server steuern?

[ddm3ve]

Du könntest es Im authorized_keys hinterlegen.

http://www.cmdln.org/2008/02/11/restric ... -commands/

Stichwort command=

[daemotron]

Weiterhin würde ich gerne einschränken, welche Befehle der Benutzer überhaupt aufrufen darf. Ist Authprog dafür noch das Tool der Wahl, oder kann man sowas inzwischen evtl. direkt im SSH-Server steuern?

So richtig gut steuern kann man das nicht. Mit ForceCommand kann man eine Session auf ein bestimmtes Kommando festnageln, aber eben nicht auf mehrere Kommandos. Mit sftp geht das sehr gut; und falls Unison nur ein Binary hat, ließe sich das dort genauso handhaben.

Zusätzlich kann man noch UsePrivilegeSeparation auf ``sandbox'' setzen - das dürfte schon sehr ausbruchsicher sein.