Immer mal wieder ... root und das su

Hi @all,

jeder der sich mal eingehender mit NFS_V3 beschäftigt hat kennt das Problem ... wenn z.B die Homeverzeichnisse per NFS gemountet werden, hat der lokale User root im Prinzip Zugriff auf alle Daten der User die ihre Homes eigentlich auf einem entfernten Server liegen haben. Ein einfaches su username reicht und root "ist" dieser User ... mit allen Rechten.

In manchen Situationen möchte man einem User aber die Rechte geben seinen Rechner selber zu administrieren ... und wenn es nur über sudo ist .... und selbst wenn der lokale User root gar nicht existiert ... mit sudo -i hat man dann eine root-Shell ... mit dem oben genannten Problem.

Was also tun ??? Kein NFS benutzen und die Homes lokal halten ??? Keine wirkliche Alternative.

Kerberisiertes NFS4 schien der Ausweg ... da jeder User dort ein gültiges Ticket benötigt um an seine Daten zu kommen ... sollte der lokale root nicht auf Daten der User auf dem Server zugreifen können ?!?

Nun ja ... der NFS4 Server steht, Kerberos funktioniert auch, die Linux-Clients holen sich ihr Home von diesem Server und wenn man frisch nach dem booten als root ein su auf einen beliebigen User macht ist das Ergebnis so wie es ein sollte ... kein Zugriff !!! Soweit so gut

Jetzt meldet sich der erste User an, bekommt sein Kerberos Ticket und hat damit Zugriff auf seine Daten ... Aber Linux ist nun mal ein MultiUserOS ... wenn nun nämlich der "böse" User root ein su auf diesen angemeldeten User macht, klappt das su und auch der Zugriff auf dessen Daten *grummel*

Im Prinzip logisch ... denn das Ticket des Users wird ja lokal für den Zeitraum der Session in einer Keytab-Datei z.B in /tmp vorgehalten ... und wie wir ja wissen darf root lokal alles ... selbst wenn die Datei dem User gehört und mit den Rechten 700 angelegt wurde.

Nach dem ersten Frust über diese Erkenntnis dachte ich ... Ok das gilt nur für den Zeitraum in dem der User an diesem PC angemeldet ist ... Pustekuchen ... nachdem sich der User abgemeldet hat und der Keytab-File in /tmp verschwunden ist hat root immer noch die Möglichkeit mit su auf dessen Daten zuzugreifen ...
Irgendwo habe ich gelesen das der rpc.gssd auch noch einen Cache habe ... die Rede war von ca. 15 Minuten ... das kann ich bestätigen ...

Kann irgend jemand mehr dazu sagen ??? Kann man für die User ein Logout-Script schreiben das auch diesen Cache sofort bei Logout löscht ???

Ich experimentierte zur Zeit mit pam_mount um das Verzeichnis der User erst bei einem Login zu mounten und beim Logout wieder auszuhängen ... aber irgendwie klappt das nicht ... pam_mount fragt nach einem Passwort (trotz Kerberos-Ticket und use_first_pass) und bekomme im Debug ähnliche Meldungen wie hier ->

http://www.linux-club.de/viewtopic.php?f=6&t=101338&start=0

Des weiteren sehe in den Logs das pam_mount mit sogenannten pre- und post-uids arbeitet und für den mount Vorgang scheinbar auf uid und gid 0 wechselt ( vermutlich um mounten zu dürfen) ... damit klappt das irgendwie nicht richtig ... anderseits habe ich gelesen das bei pam_mount in Verbindung mit cifs der lokale Mountpoint dem User gehören muss damit es klappt ?!?

Naja ... NFS4 ist deutlich schneller als NFS3 und mit Kerberos ist die ganze Sache auch sicherer geworden ... aber vollkommen glücklich bin ich mit dieser Lösung nicht *grummel*

Oder habe ich da was übersehen ???

Wäre über jeden Hinweis froh ...

So long

ThomasF

Hallo,

root auf dem Client wird über nfs als anonymous auf dem Server abgebildet, nicht als root.
Wenn man möchte, dass root auf dem Client auf einem nfs-Verzeichnis auch root-Rechte hat, ist unter Linux in /etc/exports die Option 'no_root_squash' (also "Root nicht unterdrücken") hinzuzufügen. Bei Dir dürfte diese Option also gesetzt sein.

Aber 'mal etwas anderes: Kennst Du eine brauchbare Anleitung zur Konfiguration von nfs-v4? Ich hatte beim Suchen danach (vor längerer Zeit) nichts brauchbares gefunden.

Gruß, ixo

Hallo ixo,

das Problem ist nicht das der lokale root auf dem Server Rechte hat ... das kerberisierte NFS4 Verzeichnis wird ja beim booten schon in der fstab gemountet und root kommt nur soweit es die Rechte zulassen

Aber der lokale root auf dem Client kann eben mit su zu einem beliebigen User werden ... getent passwd eingeben ... sich einen User aussuchen (z.B xyz) ... dann mit su xyz die Identität des Users annehmen ... und mit id sieht man das man die uid und gid des Users hat.

Das hat mit root_squash nichts zu tun ... aber danke für die Antwort

Das mit einer Anleitung ist so eine Sache ... als Kerberos Server dient bei uns ein Windows 2003 Server mit Active Directory ... als NFS4 Server ein Opensolaris 2008.11 Upgrade auf Build 108 ( kann ich als Fileserver nur empfehlen)

Die Doku von Sun ist sehr gut und umfangreich ... eine reine Linux Implementation möchte ich aber später auch mal durchspielen ...

Wenn sich hier ein paar Leute finden die Interesse an diesem Thema haben könnte man ja zusammen daran arbeiten und eine Doku schreiben !?!

Hast du denn schon mal NFS4 ohne Kerberos eingerichtet, lohnt sich IMHO schon wegen der Performance ??? ...

So long

ThomasF

Aber der lokale root auf dem Client kann eben mit su zu einem beliebigen User werden ... getent passwd eingeben ... sich einen User aussuchen (z.B xyz) ... dann mit su xyz die Identität des Users annehmen ... und mit id sieht man das man die uid und gid des Users hat.

Zum Vergrößern anklicken....

Das ist natürlich richtig - ich hatte das Problem offensichtlich falsch verstanden. Aber was Du beschreibst, ist doch ein generelles (bei NFSv2/3 natürlich verschärftes) Problem, wenn nicht vertrauenswürdige Rechner ins Netz kommen. Das einzige was mir dazu einfällt, ist per iptables alle nicht erlaubten IP- und MAC-Adressen dicht zu machen. Die kann man natürlich auch noch fälschen, ist aber erst 'mal nicht so einfach - man kann ja auch loggen, wenn sich jemand hereinhängt (bzw. versucht auf den NFS Server zu kommen), dann fällt das erst 'mal auf. :???:

Man kann natürlich auch für jeden Rechner ein vpn einrichten .

Hast du denn schon mal NFS4 ohne Kerberos eingerichtet, lohnt sich IMHO schon wegen der Performance ??? ...

Zum Vergrößern anklicken....

Leider nein - ich hatte 'mal versucht (ein paar Jahre her) es einzurichten, es hat aber nicht geklappt. Ich würde eine Anleitung gern hier einbauen - wäre sicher nicht uninteressant dafür.

Gruß, ixo

Hallo ixo,

Aber was Du beschreibst, ist doch ein generelles (bei NFSv2/3 natürlich verschärftes) Problem, wenn nicht vertrauenswürdige Rechner ins Netz kommen. Das einzige was mir dazu einfällt, ist per iptables alle nicht erlaubten IP- und MAC-Adressen dicht zu machen. Die kann man natürlich auch noch fälschen, ist aber erst 'mal nicht so einfach

Zum Vergrößern anklicken....

Hehe ... nun in einem Punkt hast du recht ... diese und weitere Probleme mit NFSv2/3 sind alt bekannt ... aber genau darin gesteht ja die Motivation sich mit NFSv4 zu beschäftigen.

Denn NFSv2/3 sind "Hostbasiert" spricht Hosts werden nur anhand ihrer IP erkannt ... möglich ist aber z.B in der /ec/exports auf dem Server eine Liste zu pflegen in der nur einzelne PCs stehen und nicht ganze Netze ... auch kannst du die MAC jedes Rechners kontrollieren und es gibt auch Dienste die Veränderungen von MACs zu IP Adressen melden .... Aber auch MAC Adressen kann man fälschen

NFSv4 mit Kerberos ist prinzipiell "Userbasiert" ... dies bedeutet das es eben nicht ausreicht wenn der Client eine bestimmte IP hat ... er benötigt eben auch ein Kerberos Ticket ( /etc/krb5.keytab) ... somit kann sich ein fremdes Notebook nicht mal eben das NFS Verzeichnis mounten selbst wenn es sich eine IP aus dem "richtigen" Netz besorgt... Soweit so gut ... also schon mal ein riesen Schritt in die richtige Richtung.

Um mein Problem zu verstehen, stell dir mal bitte eine große Firma vor oder eine Uni ... dort gibt es verschiedene "Benutzergruppen" ... dabei meine ich noch nicht mal Abteilungen sondern z.B die Unterscheidung in "normale" User und auf der anderen Seite "Admins". Der normale User darf im Prinzip bei NFSv2/3 niemals lokale root Rechte erhalten da er damit eben die Möglichkeit erhält auf die Dateien anderer User zuzugreifen, die er eben nicht haben sollte. Stell dir weiter vor das es "normale" Benutzer gibt die z.B unter Linux entwickeln und oft neue Pakete installieren müssen und daher aus rein praktischen und Zeit-technischen Gründen sudo, also root Rechte erhalten sollen !?!

Der Aufwand so etwas "sicher" anzubieten ist ohne NFSv4 mit Kerberos recht hoch ( vorstellbar wäre, wenn dieser User hauptsächlich nur an einem PC arbeitet, sein Home lokal zu halten ( .* Dateien) und seine "wichtigen" Daten per SMB/CIFS in sein Home per pam_mount zu mounten. Oder per NFSv2/3 sein Home ganz alleine auf dem Server exakt nur für seinen Rechner zu exportieren.

Ich hatte eben zu Anfang die falschen Vorstellungen von NFSv4 und war doch ein wenig enttäuscht das es nicht das Allheilmittel für alle Probleme darstellt.
Wie auch immer, die Arbeit war nicht umsonst, alleine wegen der Performance und den ACLs von NFSv4 hat es sich gelohnt
In Sachen Sicherheit bleibt eben dieser eine Punkt mit dem su ... den muss man noch in den Griff bekommen ... im Zweifel eben mit organisatorischen Mitteln *fg*

So long

ThomasF

ThomasF schrieb:

Ich experimentierte zur Zeit mit pam_mount um das Verzeichnis der User erst bei einem Login zu mounten und beim Logout wieder auszuhängen ... aber irgendwie klappt das nicht ... pam_mount fragt nach einem Passwort (trotz Kerberos-Ticket und use_first_pass) und bekomme im Debug ähnliche Meldungen wie hier ->

http://www.linux-club.de/viewtopic.php?f=6&t=101338&start=0

Des weiteren sehe in den Logs das pam_mount mit sogenannten pre- und post-uids arbeitet und für den mount Vorgang scheinbar auf uid und gid 0 wechselt ( vermutlich um mounten zu dürfen) ... damit klappt das irgendwie nicht richtig

Zum Vergrößern anklicken....

"Irgendwie" gibt's nicht. Da ist doch bestimmt mehr zu berichten!

... anderseits habe ich gelesen das bei pam_mount in Verbindung mit cifs der lokale Mountpoint dem User gehören muss damit es klappt ?!?

Zum Vergrößern anklicken....

Wird alles automatisch geregelt. Am besten nochmal mit neuerer Version (siehe Thread dort) versuchen.

Thomas wieso können deine Benutzer den "su - xyz" überhapt machen? Da braucht der Benutzer doch das Passwort von xyz :schockiert: Wenn sich bei mir ein Benutzer am Client anmeldet hat der nur Rechte an seinem Verzeichnis der lokale root hat keine Rechte. Wenn natürlich ein Benutzer sein PW am Bildschirm mit Post-it befestigt, dann kommt natürlich jeder mit "su - xyz" auf dessen Daten da nützt auch kein Kerberos und nfs4 :roll:. Da NFS3 host basiert ist, würde ich immer die erlaubten Hosts in die exports eintragen und in großen Umgebungen die Switche pro Port für eine MAC-Adresse beschränken. Klar kann man eine MAC auch ändern, aber wer Daten klauen will, findet immer einen Weg.

Das Problem tritt dann auf, wenn jemand z.B. seinen Laptop ins Netz hängt, auf dem er Root Rechte hat. Dann ist `su - xyz` kein Problem.

Gruß, ixo

Das stimmt natürlich. Dann habe ich aber eventuell noch viel mehr Probleme als nur NFS.

Hmm,

@stka

Nein Stefan ... ich meine nicht das ein User abc direkt su xyz machen kann ... in diesem Fall muss man natürlich ein Passwort eingeben.
Das Problem tritt dann auf wenn der User abc bei Ubuntu z.B in der /etc/group in den Gruppen adm und admin eingetragen wird ...
Wenn dieser User abc dann ein sudo -i ausführt und sein "eigenes" Passwort eingibt hat er eine Root-Shell ... mit allem was dazu gehört.
Und in dieser Root-Shell geht dann auch su xyz ohne das nach einem Passwort gefragt wird ...

@ixo

Das Problem tritt dann auf, wenn jemand z.B. seinen Laptop ins Netz hängt, auf dem er Root Rechte hat. Dann ist `su - xyz` kein Problem.

Zum Vergrößern anklicken....

Und nein ixo ... das geht nur bei NFSv2/3 oder NFSv4 ohne Kerberos ... NFSv4 "mit" Kerberos ist für dieses Szenario unempfindlich !!!

So long

ThomasF

:schockiert: :schockiert: Wer packt den auf einen *ubuntu System einen "normalen" Benutzer in die Gruppe admin?
Das muss doch nicht sein. Die Benutzer kommen doch entweder aus dem LDAP oder dem AD und brauche keine Mitgliedschaft in der Gruppe.

Hi,

weiter oben hatte ich ja geschrieben :

Stell dir weiter vor das es "normale" Benutzer gibt die z.B unter Linux entwickeln und oft neue Pakete installieren müssen und daher aus rein praktischen und Zeit-technischen Gründen sudo, also root Rechte erhalten sollen !?!

Zum Vergrößern anklicken....

Es ist bei uns nicht unüblich User die eigentlich über die ADS authentifiziert werden in der /etc/group in verschiedene Gruppen zu packen, damit sie auf dem Rechner arbeiten können ( tty, plugdev, video usw.)
Einen Domain-User in die /etc/group unter adm und admin einzutragen bedeutet ihm "lokale" root Rechte zu geben ohne das er das eigentliche Root Passwort kennen muss ...
Unter Windows ist das gleichbedeutend mit den Domain User in die "lokale" Gruppe der Administratoren zu packen ...
Das erzeugt unter Windows zwar manchmal Probleme .... Das z.B auf Software die von diesem User installiert wurde von anderen Usern nicht zugegriffen werden kann ... aber ist dennoch nicht unüblich ...

Wenn du auch nur einen anderen Weg kennst, einem Domain User auf einem Linux Client das Recht zu geben auf /dev/video0 zuzugreifen wäre ich dir sehr dankbar :


Das gleiche gilt wenn man erlauben will das ein User auf ein USB Device zugreifen können soll ...

So long

ThomasF

@jengelh

Sorry, ich hätte wissen müssen das das Erwähnen vom pam_mount eine Reaktion von dir auslöst ...

Wie ich oben ja sagte, "experimentiere" ich nur damit, wobei mir eigentlich schon klar war, das pam_mount für mein "Problem" keine wirkliche Lösung bietet.
Allenfalls 15 Min weniger Zeit für root auf die Userdaten zugreifen zu können.

Natürlich würde mich auch interessieren was intern so in pam_mount geschieht ... aber das hat Zeit ...

@all

Das eigentliche Problem ist sehr komplex und beginnt schon mit der Server/Client Architektur und mit der Grundfunktion von root als "Superuser".
Wenn jemand also root Rechte auf dem Client besitzt, besitzt er auch damit auch die Möglichkeit den Client entsprechend zu modifizieren.
Auch Kerberos lässt sich so aushebeln, dann nämlich wenn das Ticket in falsche Hände gerät und zwar solange das Ticket gültig ist.
Und der Server kann ja eben nur diesen Tickets vertrauen ...

Was bleibt ist die Notwendigkeit sich genug Wissen anzueignen um einschätzen zu können was geht und was nicht ...

Ich würde mich deshalb auch weiterhin freuen wenn sich noch andere User zu diesem Thema äußern ...

So long

ThomasF

ThomasF schrieb:

@jengelh
Das eigentliche Problem ist sehr komplex und beginnt schon mit der Server/Client Architektur und mit der Grundfunktion von root als "Superuser".
Wenn jemand also root Rechte auf dem Client besitzt, besitzt er auch damit auch die Möglichkeit den Client entsprechend zu modifizieren.
Auch Kerberos lässt sich so aushebeln, dann nämlich wenn das Ticket in falsche Hände gerät und zwar solange das Ticket gültig ist.
Und der Server kann ja eben nur diesen Tickets vertrauen ...

Ich würde mich deshalb auch weiterhin freuen wenn sich noch andere User zu diesem Thema äußern ...

Zum Vergrößern anklicken....

Ich sehe das nicht so wirklich als Problem. Es muss auf einem Rechner immer eine Instanz geben, die alle Rechte hat oder sich alle Rechte beschaffen kann. Wenn man also jemanden unbedingt Sonderrechte einräumen muss, dann sollte man das über sudo machen und nur die Befehle zulassen, die unbedingt benötigt werden. Wobei man da natürlich auch aufpassen muss.

Wie du schon sagtest, hat jemand der Root Rechte besitzt auch die Möglichkeit den Rechner zu modifizieren. Daher gibt es auch keine Möglichkeit das Problem mit den Kerberos Tickets irgendwie zu umgehen. Man könnte zwar mit SELinux die Rechte von root einschränken und ihn dann nicht mehr auf den Ticket Cache zugreifen lassen aber das bringt im Endeffekt gar nix. Was machst du, wenn:

- Root den Kernel austauscht und damit SELinux aushebelt.
- Root den SSH/login/kdm/gdm daemon modifiziert und die Passwörter einfach mitloggt
- Root einen Keylogger installiert und alle Tastatureingaben und damit die Passwörter mitloggt.

Sobald man root Zugang hat, gibt es unendlich viele Möglichkeiten an die Daten/Passwörter der User zu kommen - ein Kerberos Ticket is da das kleinste Problem, weil man eh leicht an die Passwörter der User rankommt. Daher ist die Kerberos Variante das sicherste was man hinbekommen kann. Wenn sich ein User niemals auf einem kompromitierten Rechner einloggt, dann kann auch niemand an seine Daten kommen und das ist der einzige Schutz, den dir Kerberos bietet.

Temar