Hintergrund für unsichere Standardberechtigung und -umask

[ruffy87]

Hallo zusammen,

warum ist die Standardberechtigung der home-Verzeichnisse und /root so locker gesetzt? Bei 755 kann doch jeder Benutzer die Dateien des anderen Benutzers und sogar von root lesen! Bei der standardmäßigen umask habe ich genau die selbe Frage. Eine umask von 022 ist meiner Meinung nach auch viel zu freigiebig. Dadurch entstehen auch wieder Verzeichnisse und Dateien die jeder lesen kann! (Zum Glück schränken Programme wie z.B. icedove und iceweasel die Berechtigung für ihre Benutzerordner automatisch ein.)

Diese Einstellung ist natürlich hauptsächlich für Mehrbenutzersysteme wichtig. Denn wer will schon, dass Kollegen oder Kommilitonen die eigenen Dateien lesen dürfen. Für gemeinsame Arbeiten können ja extra Tausch-Verzeichnisse eingerichtet werden oder nur einzelne Dateien/Verzeichnisse im home-Verzeichnis freigegeben werden.

Aber auch bei Systemen mit nur einem Benutzer neben root, könnte ich mir Probleme vorstellen. Wenn z.B. ein FTP-Server von einem Hacker gekapert wird, könnte der Hacker über den FTP-Server einfach auf die Daten des Benutzers zugreifen. Vorausgesetzt, der ausführende Benutzer des FTP-Servers ist nicht root. Denn sonst wäre es egal wie die home-Verzeichnisberechtigung gesetzt ist, da root auf alle Daten zugreifen darf.

Auf Anhieb habe ich auch keine Erklärung per Internetrecherche und der Suche hier im Forum erhalten. Ich bin nur auf den Thread "Zugriffsrechte auf Eigene Dateien" gestoßen, der aber eher darauf eingeht, wie man diesen Zustand ändert.

Ich benutze übrigens Debian GNU/Linux 5.0.3 beim vorherigen Release war das aber auch schon so.

Schon mal vielen Dank für eure Antworten!

Beste Grüße

Stefan

[bbcshokker]

Ist bei Debian standard, kann man jetzt drüber streiten, wenn man will.

Der default lässt sich mit

Code: Alles auswählen

dpkg-reconfigure adduser

ändern.

[uname]

Man könnte an geeigneter Stelle ja mal eine Diskussion anstoßen. Vielleicht gibt es dann eine Änderung in den Standardeinstellungen.
Interessant finde ich im übrigen auch bei Debian, dass man immer für jeden Benutzer standardmäßig eine eigene Gruppe anlegt. Somit sind meist Benutzer und Gruppe gleich und die Gruppe weicht immer von Other ab. Die Default-Einstellung von "umask" berücksichtigt dieses jedoch in keinster Weise. Irgendwie komisch.

[ruffy87]

Somit sind meist Benutzer und Gruppe gleich und die Gruppe weicht immer von Other ab.

Was vergleichst du hier? Wenn du nämlich zum Vergleich die Standardberechtigung der home-Verzeichnisse oder der umask nimmst, stimmt dieser Satz nicht.

Die Default-Einstellung von "umask" berücksichtigt dieses jedoch in keinster Weise. Irgendwie komisch.

Dieser Satz ist mir auch nicht klar (dafür müsste man wohl den vorherigen Satz verstehen). Wie sollte den deiner Meinung nach umask dies berücksichtigen?

[bbcshokker]

Somit sind meist Benutzer und Gruppe gleich und die Gruppe weicht immer von Other ab.

Was vergleichst du hier? Wenn du nämlich zum Vergleich die Standardberechtigung der home-Verzeichnisse oder der umask nimmst, stimmt dieser Satz nicht.

Ich denke er meint, dass da jeder user in seiner eigenen Gruppe ist, damit auch sichergestellt ist, dass
kein anderer user durch die Gruppenberechtigungen des home Ordners darauf zugreifen kann.

Die Default-Einstellung von "umask" berücksichtigt dieses jedoch in keinster Weise. Irgendwie komisch.

Dieser Satz ist mir auch nicht klar (dafür müsste man wohl den vorherigen Satz verstehen). Wie sollte den deiner Meinung nach umask dies berücksichtigen?[/quote]

Na ja, er will wohl, dass wenn der home Ordner nur durch den entsprechenden User lesbar ist,
dass dann auch alle vom User erstellten Files dies sein sollten.

Allerdings kann man ja schon garnicht in den home Ordner des anderen Users wechseln,
also ist das von daher egal.

Außerdem wirst du bei Debian wohl nicht viel erreichen,
denn es ist im Endeffekt Sache des Administrators, welche Einstellung
er bevorzugt.

[uname]

Was ich sagen wollte ist, dass einerseits Benutzer und Gruppe bei Debian übereinstimmen:

Code: Alles auswählen

id test
uid=1006(test) gid=1006(test) Gruppen=1006(test)

Auf der anderen Seite stimmen jedoch bei umask die Gruppe und Other überein:

Code: Alles auswählen

umask
0022

[WEARENOTALONE]

Eine Änderung der umask ist sicherlich nicht ganz unproblematisch. Aus den gleichen Gründen, die im ersten Beitrag bereits erläutert werden, habe ich meine umask auf 0077 geändert. Es gab damit allerdings schon einige Probleme, wenn sie auch bisher nie kritisch waren. Mir fällt spontan ein, dass KDM beim Login keine vom Benutzer definierten Bilder mehr anzeigt (~/.face.icon), wenn KDM keine Berechtigung hat, auf das entsprechende Verzeichnis lesend zuzugreifen. Außerdem kommt es immer wieder vor, dass Konfigurationsdateien (bspw. aus /etc) angelegt werden, die lediglich vom Benutzer gelesen werden dürfen, obwohl sie standardmäßig für alle lesbar sein sollten. Manche Programme setzen auch eine umask von 0022 voraus, beispielsweise freetz.

Viele Grüße,
WANA

[habakug]

Hallo!

Dazu hat man sich im "Securing Debian HowTo" recht eindeutig geäußert:

Das Modell von Debian löst dieses Problem, indem es jedem Nutzer seine eigene Gruppe zuweist. So wird mit einer korrekten Umask (0002) und mit dem SETGID-Bit für ein Projektverzeichnis den Dateien, die in diesem Verzeichnis erstellt werden, automatisch die richtige Gruppe zugewiesen. Das erleichtert die Arbeit von Menschen, die an verschiedenen Projekten arbeiten, da sie nicht die Gruppe oder Umasks ändern müssen, wenn sie mit gemeinsam genutzten Dateien arbeiten.

Sie können allerdings dieses Verhalten verändern, indem Sie /etc/adduser.conf modifizieren. Ändern Sie die Variable USERGROUPS auf 'no' ab. Dadurch wird keine neue Gruppe erstellt, wenn ein neuer Nutzer angelegt wird. Sie sollten auch USERS_GID die GID der Gruppe zuweisen, der alle Nutzer angehören.

Gruß, habakug

http://www.debian.org/doc/manuals/secur ... 12.de.html

[uname]

Das Modell von Debian löst dieses Problem, indem es jedem Nutzer seine eigene Gruppe zuweist. So wird mit einer korrekten Umask (0002)

Genau das erscheint mir sinnvoll. Aber wird es denn standardmäßig durchgeführt? Vielleicht liegt es ja auch an meinem Sarge -> Etch -> Lenny-Upgrade, dass ist noch eine umask=0022 habe. Vielleicht kann das mal jemand verifizieren.

Code: Alles auswählen

root@server:~# useradd bla
root@server:~# su - bla
Kein Verzeichnis, Anmeldung mit HOME=/
bla@server:/$ umask
0022

[123456]

habe hier auch nur eine Sarge auf Lenny Maschine.

Code: Alles auswählen

mini:~# grep umask /etc/profile
umask 022

[uname]

Habe noch einen V-Server auf Lenny-Basis mit Kernel 2.6.18-128.1.1.el5.028stab062.3 (openVZ)

Code: Alles auswählen

fgrep umask /etc/profile
umask 022

[uname]

Habe gerade geschaut. Auf einem echten Lenny ist es auch "umask 022" in /etc/profile.

[ruffy87]

Im WWW habe ich einen gemeldeten Bug in adduser gefunden, in dem auch verlangt wird, das Home-Verzeichnis mit 700 anstatt 755 zu setzen. Dies will der Maintainer aber nicht. Auf die Fragen warum denn die Berechtigungen so gesetzt sind, hat er nur geantwortet, dass dies aus historischen Gründen sei und schon immer so gemacht wurde. Außerdem gibt es einen Weg zum ändern der Standardeinstellung und dieser würde zu Problemen bei existierenden Installationen führen. Er weiß aber auch nicht, welche Art von Problemen dabei genau auftauchen, da er darüber noch nicht nachgedacht hat.
Super, oder? Eine Fehlkonfigurationen, die Debian wohl nicht so schnell los wird...

Hier mal der Link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202944

Ich glaube auch, das vielen Debian-Benutzern dieser Umstand gar nicht bekannt ist. So sind z.B. die meisten Home-Verzeichnisse meiner Hochschule auf 755 gesetzt.

[gms]

Er weiß aber auch nicht, welche Art von Problemen dabei genau auftauchen, da er darüber noch nicht nachgedacht hat.
Super, oder?

Dieses Problem ist aber auch wirklich nicht im "adduser" Paket zu suchen, bzw bei dessen Maintainer. Die gleichen Einstellungen werden z.B auch beim "passwd" Paket für "useradd" verwendet und das Homeverzeichnis vom "root" User steckt im Paket "base-files".

Eine Fehlkonfigurationen, die Debian wohl nicht so schnell los wird...

Hier mal der Link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202944

Ich glaube auch, das vielen Debian-Benutzern dieser Umstand gar nicht bekannt ist. So sind z.B. die meisten Home-Verzeichnisse meiner Hochschule auf 755 gesetzt.

Ich finde zwar auch, daß dieser Umstand schon die längste Zeit hätte geändert werden sollen, insbesondere beim "/root" Verzeichnis habe ich mich noch jedesmal darüber geärgert, wenn ich dieses umgesetzt habe, aber für die "Fehlkonfiguration" an deiner Hochschule zeichnet doch hauptsächlich der Admin verantwortlich, oder das System wurde bewußt so eingerichtet

Gruß
gms

edit: hier gibt es einen ähnlichen Bugreport für "base-files", also darüber kann man eigentlich nur mehr den Kopf schütteln:

Last time I checked, home directories in /home are 755 by default and
this is not considered as a bug either.

I think both cases are similar and we should treat them the same, that is,
if the consensus is that user home directories should be private by default,
we apply that principle to both /home/* and /root.

also wenn der Maintainer von "base-files" erstmal gucken muß, wie die normalen Homeverzeichnisse angelegt werden, damit er dann die falsche Entscheidung für das /root Verzeichnis trifft

[ruffy87]

Dieses Problem ist aber auch wirklich nicht im "adduser" Paket zu suchen, bzw bei dessen Maintainer. Die gleichen Einstellungen werden z.B auch beim "passwd" Paket für "useradd" verwendet und das Homeverzeichnis vom "root" User steckt im Paket "base-files".

Ein großer Teil des Problems ist schon im Paket adduser zu suchen, da mit diesem Befehl hauptsächlich Benutzer angelegt werden. Denn useradd ist nur ein low-level Werkzeug. Debian-Administratoren sollten stattdessen für gewöhnlich adduser verwenden (siehe dazu die man-Page von useradd).

In der Konfigurationsdatei von adduser (/etc/adduser.conf) gibt es nämlich die Option DIR_MODE, welche für die Berechtigung der neu erstellten home-Verzeichnisse zuständig ist. Für die Standardeinstellung von 755 ist natürlich der Maintainer verantwortlich.

[gms]

Dieses Problem ist aber auch wirklich nicht im "adduser" Paket zu suchen, bzw bei dessen Maintainer. Die gleichen Einstellungen werden z.B auch beim "passwd" Paket für "useradd" verwendet und das Homeverzeichnis vom "root" User steckt im Paket "base-files".

Ein großer Teil des Problems ist schon im Paket adduser zu suchen, da mit diesem Befehl hauptsächlich Benutzer angelegt werden.

man kann durchaus darüber spekulieren, mit welchem Befehl "hauptsächlich" Benutzer angelegt werden. Sinn wird es aber keinen ergeben, wenn hier die diversen Paketbetreuer je nach eigenem Gutdünken unterschiedliche Defaultwerte für die Homeverzeichnisse setzen. Hier ist ganz klar eine grundsätzliche Entscheidung gefragt.

Beim /root Verzeichnis sollte sich, meiner Meinung nach, eigentlich das Debian Security Team einschalten.

Gruß
gms

[chrisbra]

Im WWW habe ich einen gemeldeten Bug in adduser gefunden, in dem auch verlangt wird, das Home-Verzeichnis mit 700 anstatt 755 zu setzen. Dies will der Maintainer aber nicht. Auf die Fragen warum denn die Berechtigungen so gesetzt sind, hat er nur geantwortet, dass dies aus historischen Gründen sei und schon immer so gemacht wurde. Außerdem gibt es einen Weg zum ändern der Standardeinstellung und dieser würde zu Problemen bei existierenden Installationen führen. Er weiß aber auch nicht, welche Art von Problemen dabei genau auftauchen, da er darüber noch nicht nachgedacht hat.
Super, oder? Eine Fehlkonfigurationen, die Debian wohl nicht so schnell los wird...

Hier mal der Link: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202944

Ich glaube auch, das vielen Debian-Benutzern dieser Umstand gar nicht bekannt ist. So sind z.B. die meisten Home-Verzeichnisse meiner Hochschule auf 755 gesetzt.

Ja, unter anderem, damit mod_userdir beim Apachen funktioniert.

[paniccinap]

danke!
genau nach einem solchem thread suche ich seit ca. 1 jahr. ich hatte die frage mehrmals gestellt und immer die umask und nochwas anderes (habs vergessen) als antwort bekommen. ich möchte das nochmal aus anwendersicht darstellen, weil damit schon mal fast echter ärger "über linux" mit dem reizwort "benutzerrechte" geworden ist. Da kam dann schnell der vergleich zu einem anderen betriebsprogramm (um mal mit bild-sprech zu reden), bei dem dieses problem nicht bestehen würde...

also ein ganz einfaches problem: ein debian default system (zu der zeit noch 4.0 "etch") mehrere benutzer/innen mit home-verzeichnis. je nach dem, wer gerade vor dem rechner sitz, bleibt bei einem benutzerwechsel das gerade offene benutzerkonto aktiv. will die person dann auf die unter dem fremdkono erstellte und ins eigene home-verzeichnis verschobene datei bearbeiten - probleme wegen mangelnden benutzerrechten. gerade bei der zusammenarbeit an texten mit mehrmaligem hin- und herschieben ist das wirklich nervig (wenn mensch sich mit benutzerrechten auskennt) oder ein echtes hindernis an der weiterarbeit, wenn mensch sich mit sowas nicht auskennt.

ein benutzer-freundliches default oder möglichkeit der gruppenzugehörigkeit bei dateien und verzeichnissen für personen, denen man vertraut, wäre wirklich notwendig. und zwar für zugriff, lesen und schreiben. die individuellen zugriffsrechte pro datei kann man ja nach bedarf anpassen.

es wäre echt nett, wenn jemand hier eine lösung dazu anbieten könnte, z.b. im wiki...

[gms]

ein benutzer-freundliches default oder möglichkeit der gruppenzugehörigkeit bei dateien und verzeichnissen für personen, denen man vertraut, wäre wirklich notwendig. und zwar für zugriff, lesen und schreiben.

mit einem "benutzer-freundlichen default" kann man es ganz offensichtlich auch nicht allen recht machen

will die person dann auf die unter dem fremdkono erstellte und ins eigene home-verzeichnis verschobene datei bearbeiten

du brauchst also noch das Schreibrecht auf das fremde Homeverzeichnis, ansonsten verstehe ich aber nicht wo dein Problem liegt:

Code: Alles auswählen

root@gms2:/home# useradd -m test1
root@gms2:/home# useradd -m test2
root@gms2:/home# usermod -G test1,test2 test1
root@gms2:/home# usermod -G test1,test2 test2
root@gms2:/home# chmod g+w test*
root@gms2:/home# su - test1
test1@gms2:~$ umask 002
test1@gms2:~$ echo -n "hello" >test.txt
test1@gms2:~$ logout
root@gms2:/home# su - test2
test2@gms2:~$ mv ../test1/test.txt .
test2@gms2:~$ echo " world" >>test.txt
test2@gms2:~$ cat test.txt
hello world

Gruß
gms