[gelöst] NFS4 Export und no_root_squash

[san04]

Hallo zusammen,

ich habe bei meinem Debian einen NFS4-Share angelegt, /etc/exports schaut folgendermaßen aus:

Code: Alles auswählen

/srv/nfsv4   192.168.178.0/24(rw,sync,all_squash,anonuid=1000,anongid=1000,no_subtree_check,fsid=0)
/srv/nfsv4/Backup_HA  192.168.178.0/24(rw,sync,all_squash,anonuid=1000,anongid=1000,no_subtree_check)

Nutzen möchte ich den Share für eine Homeassistant-Instanz, die hier ihr Backup ablegen soll. Der Share wurde von Homeassistant nie akzeptiert, bis ich nach vielem herumprobieren gemerkt habe, dass er mit "no_root_squash" funktioniert.

Jetzt steht im Netz aber auch, dass diese Einstellung eigentlich ein Sicherheitsrisiko ist und vermieden werden sollte.

Ich hab es bisher so verstanden, dass das Squashing ja auf dem Server stattfindet, also sollte der Client doch gar nichts davon mitbekommen. Gibt es eine Option das serverseitig ans Laufen zu bekommen, ohne no_root_squash zu verwenden? (Bei Homeassistant sind die Einstellmöglichkeiten recht begrenzt)

[jph]

Ich habe eine identische Konstellation – all_squash auf fsid=0 und no_root_squash auf dem Export für HA – laufen:

Code: Alles auswählen

/srv            192.168.10.0/24(sec=krb5:sys,ro,all_squash,async,no_subtree_check,fsid=0)
/srv/homeassistant/backup	192.168.10.12(sec=sys,rw,no_root_squash,async,no_subtree_check) 192.168.10.0/24(sec=krb5,ro,root_squash,async,no_subtree_check)

Das Risiko halte ich in diesem konkreten Fall für sehr überschaubar. Es handelt sich ja um einen Export, der exklusiv für Datensicherungen von HA verwendet werden soll – dort sollte also nichts anderes drinliegen als eben die Datensicherungen von HA. Wenn darin HA mit root-Rechten herumfuhrwerken darf, dann kann er höchstens seine eigenen Datensicherungen löschen.

Du kannst ja überlegen, ob du die Sicherungen zusätzlich sichern möchtest für den Fall, dass HA ausflippt. Auf meinem Fileserver sichere ich u.a. die Konfiguration wöchentlich per borgmatic, das sichert dann auch die Backup-Verzeichnis von HA.

Nachtrag: Was du überlegen solltest, ist, Schreibzugriff nur für HA zu erlauben und alle anderen Zugriffe nur ro mit root_squash zu erlauben. Nur HA kann schreiben und ich kann immerhin lesend bspw. von meinem Laptop aus auf die Sicherungen zugreifen.

[MSfree]

Wenn darin HA mit root-Rechten herumfuhrwerken darf, dann kann er höchstens seine eigenen Datensicherungen löschen.

... oder das Dateisystem mit Daten füllen, dank root-Rechten also auch die reservierten Sektoren, Bei voller Platte hätte man dann ein Denial of Service (DoS)

...oder die Dateien auf dem Share verschlüsseln, um dich zu erpressen. Die verschlüsselten Dateien landen dann auch noch im Backup und überschreiben die vormals unverschlüsselten Dateien, wenn man das Backup nur dumm genug aufzieht. Daher Backups nie pushen sondern immer pullen und immer vollständig (mit Hardlinks) statt inkrementell.

[san04]

Vielen Dank für eure Rückmeldung.

Also liegt es nicht an einer Fehlkonfiguration von mir, sondern HA kann nicht anders mit NFS arbeiten?

Dieses Angriffszenario verstehe ich auch nicht so ganz: https://www.ctfnote.com/red-teaming/pri ... -squashing
Punkt 3. müsste doch schon direkt auf dem Server ausgeführt werden? Warum sollte man das tun?

Oder gibt es noch eine bessere Möglichkeit der Einrichtung? Auf Samba wollte ich eigentlich nicht wechseln.

[jph]

Das dort beschriebene Szenario geht davon aus, dass ein Angreifer auf der angreifenden Maschine (NFS-Client) root-Rechte besitzt, nicht aber auf der angegriffenen Maschine (NFS-Server). Du kannst dann als Angreifer vom NFS-Client aus das SUID-Bit für eine Datei auf dem NFS-Server setzen und anschließend dort Code mit root-Rechten ausführen.

Ob dieses Szenario für deinen Anwendungsfall relevant ist, kannst nur du beurteilen. (Für mich habe ich dieses Szenario als irrelevant abgetan, da kein User der HA-VM sich auf dem NFS-Server/dem Host einloggen kann.)

[san04]

(Für mich habe ich dieses Szenario als irrelevant abgetan, da kein User der HA-VM sich auf dem NFS-Server/dem Host einloggen kann.)

Könntest du das noch für mich erläutern? Ich habe HA als Image auf einem Raspi installiert. (Ich glaube es läuft dann in einem Container?) Also hat HA selbst auch keine root-Rechte und damit wäre das Szenario für mich auch irrelevant?

Nichtsdestotrotz wäre es doch wünschenswert, dass HA auch mit NFS-Shares ohne Privilegien arbeiten kann, oder?

[jph]

(Für mich habe ich dieses Szenario als irrelevant abgetan, da kein User der HA-VM sich auf dem NFS-Server/dem Host einloggen kann.)

Könntest du das noch für mich erläutern? Ich habe HA als Image auf einem Raspi installiert. (Ich glaube es läuft dann in einem Container?) Also hat HA selbst auch keine root-Rechte und damit wäre das Szenario für mich auch irrelevant?

Vom Ergebnis her ist das aber relativ ähnlich: Sowohl bei dir als auch bei mir läuft HA auf einem anderen „Rechner“. HA hat wegen no_root_squash root-Rechte, wenn es um den Zugriff auf das NFS-Backup geht und kann dort bspw. das SUID-Bit setzen. HA kann sich aber in beiden Fällen nicht auf dem NFS-Server anmelden und über eine solche Datei eine Privilege Escalation herbeiführen.

Nichtsdestotrotz wäre es doch wünschenswert, dass HA auch mit NFS-Shares ohne Privilegien arbeiten kann, oder?

Ja. Die Unterstützung für NFS-Mounts ist noch relativ frisch. Möglicherweise kommt da noch etwas.

[san04]

Vielen Dank, jetzt habe ich endlich verstanden, wie der Angriff funktioniert. Mir war vorher nicht klar, dass es für das Szenario erforderlich ist, dass sich der Nutzer unpriviligiert auf dem Server anmelden können muss um von der Vorarbeit zu profitieren. Ich dachte das Setting sei per se gefährlich und war darüber verwundert. Dann lasse ich alles so wie es ist.

Ja. Die Unterstützung für NFS-Mounts ist noch relativ frisch. Möglicherweise kommt da noch etwas.