Re: NFS-Rechte
Gruesse!
* Ruediger Noack <ernohl@yahoo.de> schrieb am [17.01.04 00:11]:
> >Tja, NFS ist für dein Vorhaben einfach nicht gemacht.
> >
> Und jetzt mal (für mich) theoretisch:
> In einer Umgebung mit Linux-Desktops wäre NFS doch naheliegend. Ist aber
> nach meinem Scenario eigentlich unverantwortlich. Da kommt jemand mit
> seinem Notebook (Linux), stöpselt sich anstelle seines Desktops mal
> vorübergehend mit der fremden IP-Adresse und mit fremdem Usernamen ins
> LAN und nimmt alle geklauten Daten fröhlich mit nach Hause. :-(
>
> So extrem hatte ich dieses Thema bisher nicht gesehen. Gut, dass wir
> darüber gesprochen haben. ;-)
Allgemein hast du recht, nur noch mal für die Genauigkeit:
a) der *Benutzername* allein langt nicht. Der BöseBube(BöBu) muß seinen
geklauten Usernamen mit den gleichen UserID/GroupID ausstatten. Auf dem
NFS-Server sind User/Group-Namen nur insofern relevant indem sie in
ensprechende UID/GID umgesetzt werden.
b) Man kann die Verzeichniss-Struktur (= Rechte-Struktur über UID/GID)
der exportierten Verzeichnisse "schmal" setzen. D.h., wenn ich /Daten
exportiere muß User Paul nicht in /Daten/Briefe schauen können, wenn er
eigentlich nur Zugriff auf /Daten/MP3 haben soll.
c) Man kann (sollte) Usern das Mounten verbieten. An importierten
(NFS/Netz-Dateisystemen nur, was root beim Systemstart fest über fstab
einmountet. Dann greift aber wieder obiges a) + b).
d) Keine Root-Rechte über NFS! nur root_squash.
e) Man kann über netfilter die IPs an bestimmte MAC-Adressen binden.
f) Den nfs-port an einen unüblichen Port (! 2049) binden.
Das fällt mir jetzt ein, um NFS etwas sicherer zu machen. Es sind
allerdings nur *Hindernisse* um einen an sich unsicheren Dienst zu
verbessern. Wenn der BöBu auf seinem Laptop über Root-Rechte verfügt und
einigermaßen versiert ist, sind das keine Hindernisse.
NFS ist also ähnlich als würde ich jeden mit einer Knoppix-CD an meinen
Server lassen, der praktischerweise noch über Schnittstellen wie Floppy,
CD-Rom, USB, ... verfügt. Würdest Du das?
Eine Alternative für den semiprofessionellen Bereich wäre noch der
Einsatz von crypto-Filessystemen, z.B. cfs (siehe apt-cache show cfs).
Du würdest dann per nfs die verschlüsselten Daten exportieren, was z.B.
so ausehen würde (wobei /data bei mir ein gemounteter NFS-Import ist):
gerhard@ws01:~$ ls /data/privat/
0538edce1bd4478516416b399aef6abb
09526e8b24fdf43c2eac25bd8d7dfed4
1f0263f3396d361a
304c9bcf76e19563
396b501b5ddcec38e42a98f041f3152d4c96a593b93eb3d0bfece74bc2e6d69d
59b429159a6fd7a95e3aadf5e787d844
5fc77b61869c1e370098d9f87d4c19c094c90964e74ef6df
68378ec77a1088fe59e34c5d3f9a7ee9
76cadfa603003b2d
7b695e0ebc1dedceaf217112b229558b
8f3b6ed227878e0bb7ed38b58419f271
98c9766315bcf7cf1e56fb0597d41bb6
9dd4ee62dce9d5304fe12f3b2b28e115
a3043240a24177fc
bf09237c4404ccea
c1fc99e3a9e16fec2eb9d3cca298ce5f6370965f86a66f34
c36c94932a2f4f4e75dd5cc948c8477c
c8d41bc32fbb7c96a22e5ba6d33ae495
c97141a1c470ed6cd1745a6866f7f685
e6f72d033ff039dd
ed85032c6a6ce34068c996a062435c413c7d2f2d8ae2e8e2
Auf dem Client wird dann vom User mittels cattach das verschlüsselte
Verzeichniss unter Abfrage einer starken Passphrase lokal eingemountet
(z.B. nach /crypt/privdata. Dort kann der User kann wieder mit den
unverschlüsselten Daten arbeiten, die weiterhin aber verschlüsselt auf
dem NFS-Server sind.
Daß kostet halt etwas CPU-Zeit auf den Clients. Obiges a) und b) gelten
aber weiterhin. Wenn der BöBu Schreibzugriff auf die verschlüsselt
abgelegten Daten erlangen sollte (über UID/GID oder als root) löscht er
halt Dateien und Verzeichnisse mit "kryptischen Inhalt". Das *Lesen* und
Nutzen der Daten ist aber nahezu unmöglich.
> Gruß
> Rüdiger
Gruß
Gerhard
Reply to: