Rechner zu sicher gemacht - nun kein Login möglich

Computer: Software & Programmierung UNIX & Linux
1

Hallo zusammen!

Ich bin gerade dabei einen FTP-Server einzurichten, um mit Lehrgangskollegen Unterrichtsmitschriften austauschen zu können.

Da die Kollegen auch schreibenden Zugriff auf den Rechner haben sollen, wollte ich den Rechner möglichst sicher vor unbefugtem Zugriff machen und habe dazu „chmod -R o-rwx /“ auf das Dateisystem losgelassen. Damit sollten die User nur auf die Verzeichnisse zugreifen können, für die sie über die Gruppenzugehörigkeit auch eine ausdrückliche Berechtigung bekommen haben - dachte ich.

Zu meinem nicht allzugroßen Erstaunen war nach der Aktion außer für Root kein Login mehr möglich.

Nachdem ich jedoch einem Testuser die Login-Shell „/bin/bash“ zugewiesen habe, und dem User sukzessive Mitgliedschaft in den Gruppen „bin“, „console“ „tty“ und „sshd“ gewährt habe, ist es immer noch nicht möglich, sich mit dessen Account auf dem Rechner einzuloggen. Dies hat mich zunehmend mehr erstaunt.

Selbst wenn ich als root „su testuser“ eingebe, erhalte ich die Meldung: „Cannot execute /bin/bash: Permission denied“

Das Verzeichnis /bin hat die Rechte/Besitz: drwxr-x— root bin
und die /bin/bash hat ebenfalls -rwxr-x— root bin.

An dieser Stelle verwandelt sich mein Erstaunen in mittleres Unbehagen. Ich weiß absolut nicht mehr weiter, da mir unklar ist, warum die Berechtigung zur Ausführung von /bin/bash nicht gegeben ist.

Den Login habe ich sowohl über einen ftp-Client als auch über ssh versucht. Ein Login von der Konsole ist leider nicht möglich, da der Rechner weder über Tastatur noch über einen Monitor verfügt.

Was muss ich anstellen, damit sich die User wieder auf dem Rechner anmelden können? „chmod -R o+rwx /“ scheint mir dabei nicht die geeignete Alternative zu sein. :wink:

Gruß

Stefan

PS: Falls das von Bedeutung ist: Distribution ist Slackware 10.2, Kernel 2.4, FTP-Daemon: vsftpd - gestartet über inetd.

2

Was muss ich anstellen, damit sich die User wieder auf dem
Rechner anmelden können? „chmod -R o+rwx /“ scheint mir dabei
nicht die geeignete Alternative zu sein. :wink:

Also, derart brutal mit den Rechten über das ganze Dateisystem zu gehen, erscheint mir sowieso nicht das richtige zu sein. Damit hast du so einiges platt gemacht - meine Empfehlung: Neuinstallation.

Warum nimmst du erst den Usern das Recht, auf /bin/bash zuzugreifen und versuchst dann über irgendwelche Krücken, ihnen das Recht wieder zu geben?

Was du willst ist doch nichts anderes als einen FTP-Zugang auf deiner Maschine. Also sichere doch das System über den FTPd - eigentlich reicht es aus, den Anwendern ein Homeverzeichnis zu geben und über die Konfiguration des FTPd ein freies Bewegen über das Dateisystem zu unterbinden (Stichworte: jailed, chrooted).

Das ist sicher genug.

Gruß,
Stefan

3

Hallo Stefan!

Also, derart brutal mit den Rechten über das ganze Dateisystem
zu gehen, erscheint mir sowieso nicht das richtige zu sein.

Jetzt erscheint mir das auch so. Allerdings frage ich mich, ob es auf einem
wasserdichten System überhaupt globale Leserechte geben sollte.

Damit hast du so einiges platt gemacht - meine Empfehlung:
Neuinstallation.

Also so einfach will ich mich dann doch nicht geschlagen geben.

Warum nimmst du erst den Usern das Recht, auf /bin/bash
zuzugreifen und versuchst dann über irgendwelche Krücken,
ihnen das Recht wieder zu geben?

Gegenfrage, warum gibt es eine Gruppe „bin“, wenn diese im Verzeichnis „/bin“
die gleichen Rechte hat, wie der Rest der Welt?
Ich sehe das so, dass bei globalen r-x-Rechten schlicht und ergreifend die
Rechteverwaltung über die Gruppen ausgeschaltet ist. Und auf einem sicheren
Rechner sollten doch die Rechteverwaltungsinstrumente nicht durch globale
rx-Rechte außer Kraft gesetzt werden, oder sehe ich das grundsätzlich falsch?

(Stichworte: jailed,
chrooted).

Da hatte ich auch erst dran gedacht, da der vsftpd das ja auch recht einfach
ermöglicht. Ziel des ganzen ist jedoch, dass die User einerseits ihren
Privatbereich haben, in dem nur sie alleine schreiben können, als auch ein
Gruppenverzeichnis, auf das alle gleichermaßen rwx-berechtigt Zugreifen können,
um kollaborativ an Dokumenten zu arbeiten.
Oder fällt dir dazu noch eine Lösung ein? Hardlinks sind sicher nicht die
Lösung, und bei Softlinks wird der Zugriff sicherlich geblockt, da die User
dann ja ihre chroot-Umgebung verlassen würden.

Gruß

Stefan

4

Hi,

Jetzt erscheint mir das auch so. Allerdings frage ich mich, ob
es auf einem
wasserdichten System überhaupt globale Leserechte geben
sollte.

wenn die login-shell die /etc/passwd nicht lesen darf, wie soll sie dann prüfen können, ob es den User der sich grade anmelden will überhaupt gibt? Wie sollen globale temporäre Dateien geprüft und angelegt werden, wenn auf /tmp nicht geschrieben werden darf?

die gleichen Rechte hat, wie der Rest der Welt?
Ich sehe das so, dass bei globalen r-x-Rechten schlicht und
ergreifend die
Rechteverwaltung über die Gruppen ausgeschaltet ist.

Wenn ich mich recht erinnere wirken die Einschränkungen auf die Gruppe trotzdem. Also wenn alle was dürfen, ich als Gruppenmitglied aber nicht, dann darf ich das in Summe auch nicht. Bin mir aber nicht ganz sicher.

cu,
J~

5

Hi,

Das ist sicher genug.

besser ist natürlich sftp.

J~

6

Hallo,

Damit hast du so einiges platt gemacht - meine Empfehlung:
Neuinstallation.

Der Empfehlung möchte ich mich in aller Deutlichkeit anschließen.

Warum nimmst du erst den Usern das Recht, auf /bin/bash
zuzugreifen und versuchst dann über irgendwelche Krücken,
ihnen das Recht wieder zu geben?

Gegenfrage,

Es ist keine gute Idee, gleich Gegenfragen zu stellen…

warum gibt es eine Gruppe „bin“, wenn diese im
Verzeichnis „/bin“
die gleichen Rechte hat, wie der Rest der Welt?

Um ehrlich zu sein: ich weiß es nicht genau. Das ist traditionell bei Slackware so ohne daß mir der Sinn bekannt wäre.

Ich sehe das so, dass bei globalen r-x-Rechten schlicht und
ergreifend die
Rechteverwaltung über die Gruppen ausgeschaltet ist. Und auf
einem sicheren
Rechner sollten doch die Rechteverwaltungsinstrumente nicht
durch globale
rx-Rechte außer Kraft gesetzt werden, oder sehe ich das
grundsätzlich falsch?

Nun, erstens muß Du Deinen Usern keine Shell geben. Dann können sie auch keine Kommandos ausführen. Zweitens können User so keine globalen Daten verändern, sondern nur ihre eigenen. Also eher kein Problem.

(Stichworte: jailed,
chrooted).

Da hatte ich auch erst dran gedacht, da der vsftpd das ja auch
recht einfach
ermöglicht.

Wobe ja eher vor einem chroot aus Sicherheitsgründen gewarnt wird.

Oder fällt dir dazu noch eine Lösung ein?

Kein chroot?

HTH,

Sebastian

7

Hallo.

These (a)

Ich sehe das so, dass bei globalen r-x-Rechten schlicht und
ergreifend die
Rechteverwaltung über die Gruppen ausgeschaltet ist.

These (b)

Wenn ich mich recht erinnere wirken die Einschränkungen auf
die Gruppe trotzdem. Also wenn alle was dürfen, ich als
Gruppenmitglied aber nicht, dann darf ich das in Summe auch
nicht. Bin mir aber nicht ganz sicher.

(b) ist richtig :wink:

Gruß,
-Andreas.