Am Freitag 18 Juli 2008 schrieb Peter Jordan:
> Hallo,
Hallo Peter!
> ist es irgendwie möglich root den Zugriff auf die home-verzeichnisse
> (und auf den mail-cache) zu verbieten, dh. das ein wechseln in diese
> Verzeichnisse oder ein auslesen der Dateien in der normalen nutzung
> nicht mehr möglich ist.
Dem am nähesten kommt wohl noch eine FUSE-Dateisystem ohne allow_user. Aus
der Kernel-Dokumentation Documentation/filesystems/fuse.txt:
'allow_other'
This option overrides the security measure restricting file access
to the user mounting the filesystem. This option is by default only
allowed to root, but this restriction can be removed with a
(userspace) configuration option.
Zum Beispiel encfs. Aus dessen Manpage:
--public
Attempt to make encfs behave as a typical multi-user
filesystem. By default, all FUSE based filesystems are
visible only to the user who mounted them. No other
users (including root) can view the filesystem con-
tents. The --public option does two things. It adds
the FUSE flags "allow_other" and "default_permission"
when mounting the filesystem, which tells FUSE to allow
other users to access the filesystem, and to use the
ownership permissions provided by the filesystem. Sec-
ondly, the --public flag changes how encfs's node cre-
ation functions work - as they will try and set owner-
ship of new nodes based on the caller identification.
Warning: In order for this to work, encfs must be run
as root -- otherwise it will not have the ability to
change ownership of files. I recommend that you
instead investigate if the fuse allow_other option can
be used to do what you want before considering the use
of --public.
Ohne --public konnte ich mich jedoch nicht via KDE auf ein via encfs
verschlüsseltes Homeverzeichnis einloggen. Mit --public geht es. Ich
vermute, das liegt daran, dass der X-Server, Displaymanager und/oder
dessen Init-Skripte, welche als Root laufen, zum Beispiel in die Datei
~/.xsession-errors oder auch ~/.Xauthority oder auch ~/.ICEauthority
schreiben möchte(n). Und das geht eben dann nicht mehr.
Ich habe das jedoch nicht genauer untersucht...
Zudem lässt sich auch diese Maßnahme via su Benutzername umgehen.
Daher muss meines Erachtens ein solcher Schutz der privaten Daten vor dem
Admin, den ich nicht von vorneherein als unnütz abtun würde, darauf
aufbauen, das Wechseln der Identität durch den Root-Benutzer
einzuschränken.
Es gibt Bestrebungen dazu, root-Rechte einzuschränkbar zu machen. So kamen
gerade in 2.6.26 file based capabilities hinzu. Auch davor war es meines
Wissens zum Beispiel möglich, mit ext2/ext3 eine Datei für root so
unveränderbar zu machen, dass dieser sie nur nach einem Reboot wieder
ändern kann (chattr +i und lcap).
Allerdings startet root auch da erstmal mit vollen Rechten und lcap nimmt
ihm davon später welche weg. Also das wasserdicht hinzubekommen ist wohl
nicht wirklich einfach ;).
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.