Secure SVN access via Dropbear chroot?

[zyrill]

Folgende Herausforderung: ich möchte einen sicheren SVN Zugang (sprich: SSH verschlüsselt) zu einem Subversion Repository auf meiner Fritz!Box ermöglichen, ohne, dass der User root bekommt und etwas anrichten kann. Geht das überhaupt?

Folgendes möchte ich nämlich nicht: irgendeinen anderen Port außer SSH öffnen, denn Dropbear akzeptiert nur Public Key Authentication und das will ich auf keinen Fall ändern - so fühle ich mich sicher. Ich möchte also insbesondere nicht einen Port für Subversion öffnen, um dort dann die ganz normale SVN Authentication ablaufen zu lassen.

Was ich bisher mache ist, per SSH auf meine Fritzbox zu tunneln und dann im Subversionclient einfach svn://localhost/ anzugeben. Damit läuft die ganze Chose über SSH und ist somit sicher. Funktioniert auch wunderbar.

Nun will ich noch jemand anderes Zugriff auf das Repository geben, der aber eben keinen root-Zugriff haben soll. Ich dachte, ich lege einfach einen neuen Benutzeraccount an, der aber außer der Loginmöglichkeit keinerlei Rechte besitzt, und sperre den Account in ein chroot (geht das überhaupt? Kann man daraus nicht ausbrechen?).

Habe ich bis hierher einen Denkfehler begangen und irgendetwas falsch verstanden, oder könnte das klappen?

Jetzt habe ich mehrere Probleme: erstens tauchen beim SSH-Login mir schleierhafte Fehlermeldungen auf (Kuriosum am Rande: obwohl bei Dropbear "Login nur für root erlauben" ausgewählt ist, komme ich mit dem neuen User trotzdem auf die Box!):

-sh: /etc/init.d/rc.conf: line 4: can't create /var/env: Permission denied
grep: /etc/default.language: Permission denied
rm: can't remove '/var/TZ': Permission denied
ln: /var/TZ: File exists

Ich habe den Fehler verfolgt: beim Login wird /etc/profile aufgerufen, welche sofort /etc/init.d/rc.conf aufruft. Ist das nötig? Kann ich das irgendwie dahingehend abändern, dass alle Aufrufe, die bei einem Account ungleich root sinnlos sind, ausgelassen werden? Im Prinzip braucht ja gar nix geladen werden, keine Aliase oder sonst etwas, denn es geht ja nur um den SSH Tunnel.

Wie sperre ich einen User in einen chroot ein und wo müsste ich die entsprechenden Befehle unterbringen?

Ist das Ganze am Ende eine Schnappsidee und ich sollte lieber einfach OpenVPN bemühen?

 

[RalfFriedl]

Kann ich das irgendwie dahingehend abändern, dass alle Aufrufe, die bei einem Account ungleich root sinnlos sind, ausgelassen werden?

Ja, kannst Du. Ich dachte, im aktuellen Trunk wäre das sowieso schon der Fall.

PS:
Deine Signatur sagt: "latest freetz-trunk". Das glaube ich Dir nicht.

 

[olistudent]

if (svr_opts.rootonlylogin && ses.authstate.pw_uid != 0) {

Diese Abfrage funktioniert so? Dann müsste es doch eigentlich passen.

Gruß
Oliver

 

[zyrill]

Jul 27 22:59:22 fritz user.notice dropbear[4575]: Password auth succeeded for 'user' from ::ffff:192.168.178.20:60465

Sowohl in der '/etc/default.dropbear/dropbear.cfg' als auch in der '/var/mod/etc/default.dropbear/dropbear.cfg' ist "export DROPBEAR_ROOTONLY='yes'", 'echo $DROPBEAR_ROOTONLY' war aber leer "" - check ich nicht. Ich habs jetzt manuell gemacht: 'export DROPBEAR_ROOTONLY'. Da stimmt irgendwas nicht...

@RalfFriedl: Ich habe hier übrigens im Moment 'freetz-devel-7419' laufen - zum Zeitpunkt des Schreibens dieses Beitrags eine tagesaktuelle Version, bei der die von Dir angemerkten Änderungen

Ich dachte, im aktuellen Trunk wäre das sowieso schon der Fall.

offensichtlich nicht gepatch sind, weil ich immer noch die im ersten Post beschriebenen Fehlermeldungen bekomme.

Nochmal meine ursprüngliche Frage: kann ich einen Benutzer irgendwie in sein Home-Verzeichnis einsperren, damit er nicht im gesamten System herumirren kann? (Ich habe schon die ganze externe Platte per 'chmod -R 750' unlesbar für den user gemacht, aber wenn es noch rigoroser ginge, wäre mir das lieber.) So geht es gar nicht... dann kommt der User gar nicht mehr in sein Verzeichnis rein und kann sich nicht mehr einloggen. Komisch... Ich glaub, ich versteh das noch nicht ganz.

Grüße!

p.s.: Signatur so besser?

 

[olistudent]

Startest du dropbear im inetd Modus?

Gruß
Oliver

 

[zyrill]

Ja, das tue ich.

Grüße!

 

[olistudent]

http://freetz.org/changeset/7430

 

[RalfFriedl]

Den User in ein chroot zu bringen ist schwierig, er müsste in dem Verzeichnis alle benötigten Programme und Libraries haben, und chroot kann nicht von einem normalen Benutzer aufgerufen werden.

Du kannst aber dem Benutzer eine Shell wie cat zuordnen, damit kann man keine Programme starten.

Mit der Signatur ist es generell so, dass sie später mal anders aussehen kann. Wenn also in einer Woche oder in einem Monat jemand diesen Thread liest, kann ein Verweis auf die Signatur sehr irreführend sein.

 

[zyrill]

olistudent: danke für den Patch bezüglich des Rootonly-logins.

RalfFriedl: ja, ich verstehe die Argumente bezüglich chroot. Ich verstehe aber nicht, wie ich cat (ich nehme an, Du meinst dieses) als Shell benutzen soll. Wenn ich in /etc/passwd anstatt /bin/sh /bin/cat eintrage, bricht PuTTY den Loginvorgang mit einem Fehler ab. Das cat, was ich meine, ist dafür ja auch nicht da... Ich benutze es immer nur zum Dumpen von kurzen Textfiles auf das Terminal. Ein anderes cat habe ich beim Googeln nicht gefunden, auch nicht in Kombination mit "shell cat" usw. Steh ich jetzt voll auf der Leitung?

Grüße.

 

[RalfFriedl]

Ja, ich meine /bin/cat. Damit dropbear es aber als Shell akzeptiert, muss es in /etc/shells eingetragen werden. Etwas besser ist evtl. ein Skript, das /bin/cat ohne Parameter aufruft. Der Effekt ist der, dass /bin/cat als Kommando-Interpreter verwendet wird. Aber die eingetippten Kommandos werden nur zurück gegeben und nicht ausgeführt, man kann also letztlich mit dieser "Shell" nichts anfangen.

Die Shells Datei kannst Du mit mount Bind modifizieren, ohne gleich eine neue Firmware zu erstellen:

cp -p /etc/shells /tmp/shells
echo /bin/cat >> /tmp/shells
mount --bind /tmp/shells /etc/shells

Danach funktioniert ein ssh Login auf einen Benutzer, der /bin/cat als Shell hat. Wenn allerdings direkt ein Kommando ausgeführt werden soll, kommt von cat eine Fehlermeldung. Das kann man mit einem Skript beheben, das alle Parameter ignoriert und /bin/cat ohne Parameter aufruft.

 

[zyrill]

Ah, ich wusste nicht von der Liste zugelassener Shells. Danke! Was ich versuchsweise gemacht habe, ist also Folgendes:

cp -p /etc/shells /tmp/shells
echo /tmp/cat >> /tmp/shells
mount --bind /tmp/shells /etc/shells

Dann die Datei "/tmp/cat" mit folgendem Inhalt erstellt:

#!/bin/sh
/bin/cat

Und weiter

chmod +x /tmp/cat

Sowie in der "/etc/passwd" die Zeile des Benutzers wie folgt abgeändert:

user1:x:1003:1003:Linux User:/var/media/ftp/USB1/home/:/tmp/cat

So funktioniert es aber nicht - tut mir leid, dass ich nochmal fragen muss! Ich weiß einfach nicht, wie ich das Shellverhalten hier debuggen soll... Wenn ich anstatt "/tmp/cat" direkt "/bin/cat" per Deiner Anleitung in der passwd eintrage, geht es - was mache ich falsch? Im syslog steht nur "... exited normally", wenn ich direkt versuche das Skript als Loginshell in der passwd einzutragen. Ich habe auch versucht, sowohl "/tmp/cat" als auch "/bin/cat" zur "/tmp/shells" hinzuzufügen, aber daran liegt es nicht.

 

[RalfFriedl]

Bei mir funktioniert das, was Du schreibst:

# cat /etc/shells
/bin/sh
/bin/ash
/bin/cat
/tmp/cat
# cat /tmp/cat
#!/bin/sh
/bin/cat

Kannst Du das Skript in/tmp/cat von Hand aufrufen?

 

[zyrill]

Ja, von Hand lässt sich das starten und gibt brav immer nur ein echo meiner Eingaben zurück, cat läuft also.

Moment mal - mirakulöserweise funktioniert es bei mir jetzt auch. Dabei habe ich nichts gegenüber gestern Nacht geändert. Auch die Box hat sich nicht neu gestartet und die Daemons habe ich ebenfalls nicht angefasst. Mir schleierhaft. Aber gut: Entschuldigung für die abermalige Nachfrage und vielen Dank für die Hilfe. Das ist spitze und genau das, was ich haben wollte! Super.

 

[RalfFriedl]

Schön, dass es funktioniert.
Wenn Du das Skript etwas komfortabler haben willst, kannst Du auch etwas in der Art machen:

#!/bin/sh

echo Login erfolgreich, keine Shell.
echo Strg-D zum Beenden.
cat > /dev/null

Damit sieht man, dass die Anmeldung durch ist, statt dessen bekommt man kein Echo