Auf Nur-Gruppen-Ordner auf Overlayfs2 auf NFSv4 mit aktiviertem root_squash zugreifen?

Question

Hintergrund

Bei einem NFSv4-Export/-Freigabe zwingt die standardmäßig aktivierte Option root_squash NFS, die Root des Clients in eine anonyme ID zu ändern. Dies erhöht tatsächlich die Sicherheit, indem verhindert wird, dass der Besitz des Root-Kontos eines Systems auf das andere System migriert wird.

Overlayfs ermöglicht es, ein lokales, transparentes Dateisystem über einem anderen Dateisystem zu mounten. Leider scheint es, als würde es auf das darunterliegende Dateisystem mit dem Root-Benutzer zugreifen und nicht mit dem tatsächlichen Benutzer. Das ist zumindest die Schlussfolgerung, die ich aus dem folgenden Experiment ziehe.

Warum ein Overlayfs über eine NFS-Freigabe mounten? Um einem weniger vertrauenswürdigen Rechner die Möglichkeit zu geben, so zu tun, als könne er in das freigegebene Dateisystem schreiben.

Versuchsaufbau

Installieren Sie zunächst den für Ihre Distribution geeigneten NFS-Kernelserver. Stellen Sie dann sicher, dass Sie nur NFSv4 exportieren. (Obwohl dies für dieses Problem wahrscheinlich nicht wichtig ist, ist es eine gute Sicherheitsvorkehrung.)

$ sudo cat /proc/fs/nfsd/versions
-2 -3 +4 +4.1 +4.2

Wenn nicht, schauen Sie nach /etc/nfs.confund legen Sie fest vers3=n.

Erstellen Sie dann ein Ext4-Dateisystem in einer Sparse-Datei und mounten Sie es auf dem lokalen Dateisystem. Dies wird das Dateisystem sein, das unserer NFS-Freigabe zugrunde liegt.

$ truncate -s 512M 512BM-ext4.img
$ mkfs.ext4 512BM-ext4.img
$ sudo mkdir /mnt/ext4-file
$ sudo mount -o loop,noacl 512BM-ext4.img /mnt/ext4-file

Geben Sie dieses Dateisystem dann über das Netzwerk mit NFSv4 frei bzw. exportieren Sie es auf eine geeignete Maschine. In diesem Beispiel verwende ich localhost, es könnte aber jede andere Maschine im lokalen Netzwerk sein. Bearbeiten Sie dazu die /etc/exportsZeile so, dass sie wie die folgende aussieht.

/mnt/ext4-file/ localhost(ro,fsid=123123)

Starten Sie dann den NFS-Server auf Ihrem Computer neu. Die Servicedateien können auf Ihrem Betriebssystem anders sein.

$ sudo systemctl restart nfs-server.service nfs-mountd.service
$ sudo exportfs -v
/mnt/ext4-file  localhost(sync,wdelay,hide,no_subtree_check,fsid=123123,sec=sys,ro,secure,root_squash,no_all_squash)

Stellen Sie sicher, dass root_squashund roaktiviert ist.

Jetzt sollte es möglich sein, die NFSv4-Freigabe auf Ihrem gewünschten Client zu mounten.

$ sudo mount -t nfs -o ro localhost:/mnt/ext4-file /mnt/nfs-share/
$ findmnt /mnt/nfs-share 
TARGET         SOURCE                   FSTYPE OPTIONS
/mnt/nfs-share localhost:/mnt/ext4-file nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255

Und dann mounten wir overlayfs2 über dieser Freigabe.

$ mkdir -p /tmp/overlay/{work,upper}
$ sudo mkdir /mnt/overlay
$ sudo mount -t overlay overlay -o lowerdir=/mnt/nfs-share/,upperdir=/tmp/overlay/upper/,workdir=/tmp/overlay/work/ /mnt/overlay/

Für unser Experiment erstellen wir einen Ordner im Dateisystem, der nur von einem Benutzer gelesen und beschrieben und von einer Gruppe gelesen werden kann. Ich habe die Gruppe gewählt, die meinem Benutzer gehört.

$ sudo mkdir /mnt/ext4-file/rovanion
$ sudo chown rovanion:rovanion /mnt/ext4-file/rovanion
$ sudo chmod 2750 /mnt/ext4-file/rovanion
$ touch /mnt/ext4-file/rovanion/hi-from-ext4
$ ls -la /mnt/nfs-share/rovanion/
totalt 8,0K
drwxr-s--- 2 rovanion rovanion 4,0K sep  6 14:14 .
drwxr-xr-x 4 root     root     4,0K sep  6 14:12 ..
-rw-rw-r-- 1 rovanion rovanion    0 sep  6 14:14 hi-from-ext4
$ touch /mnt/nfs-share/rovanion/hi-from-nfs
touch: cannot touch '/mnt/nfs-share/rovanion/hi-from-nfs': Read-only file system

Wir können den Inhalt von auflisten /mnt/nfs-share/rovanion, können das Dateisystem jedoch nicht berühren, obwohl wir die Berechtigung dazu haben, da die NFS-Freigabe schreibgeschützt gemountet ist. Alles ist wie erwartet.

Versagen

Aber hier kommt das Problem.

$ ls -la /mnt/overlay/rovanion/
ls: cannot open directory '/mnt/overlay/rovanion/': Permission denied
$ ls -l /mnt/overlay/
total 28K
drwx------ 2 root     root      16K Sep  6 13:04 lost+found
drwxr-s--- 2 rovanion rovanion 4.0K Sep  6 14:14 rovanion
$ whoami
rovanion
$ groups
rovanion sudo

Uns wird der Zugriff auf die Liste verweigert, /mnt/overlay/rovanionobwohl das Berechtigungssystem uns dies ermöglichen sollte.

Meine beste Vermutung ist, dass Overlayfs den gesamten Zugriff auf das zugrunde liegende Dateisystem durchführt, rootdas vom Root-Squash von NFS nobodydemjenigen zugeordnet wird, der keinen Zugriff auf den Ordner hat, da nobodyer nicht zur Gruppe gehört rovanionund andere den Ordner nicht auflisten dürfen.

Frage

Meine Frage ist dann: Ist es möglich, dieses Problem zu umgehen? Einem Benutzer über Overlayfs Zugriff auf einen Ordner zu gewähren, auf den nur eine ausgewählte Gruppe Zugriff hat, ohne root_squash beim NFS-Export/der NFS-Freigabe zu deaktivieren oder o+rxzum Ordner hinzuzufügen.

Answer 1

Der folgende Abschnitt derLinux-Kernel-Dokumentation zu Overlayfsbeschreibt das Berechtigungsmodell.

Die Berechtigungsprüfung im Overlay-Dateisystem erfolgt nach diesen Grundsätzen:

1) permission check SHOULD return the same result before and after copy up
2) task creating the overlay mount MUST NOT gain additional privileges
3) non-mounting task MAY gain additional privileges through the overlay, compared to direct access on underlying lower or upper filesystems

Dies wird erreicht, indem bei jedem Zugriff zwei Berechtigungsprüfungen durchgeführt werden

a) check if current task is allowed access based on local DAC (owner, group, mode and posix acl), as well as MAC checks
b) check if mounting task would be allowed real operation on lower or upper layer based on underlying filesystem permissions, again including MAC checks

Mit der Prüfung (a) wird die Konsistenz sichergestellt (1), da Besitzer-, Gruppen-, Modus- und POSIX-ACLs kopiert werden. Andererseits kann es dazu führen, dass vom Server erzwungene Berechtigungen (wie sie beispielsweise von NFS verwendet werden) ignoriert werden (3).

Durch die Prüfung (b) wird sichergestellt, dass keine Aufgabe Berechtigungen für darunterliegende Ebenen erhält, über die die Mounting-Aufgabe nicht verfügt (2).Dies bedeutet auch, dass es möglich ist, Setups zu erstellen, bei denen die Konsistenzregel (1) nicht gilt; normalerweise verfügt der Mount-Task jedoch über ausreichende Berechtigungen, um alle Operationen auszuführen.

Hervorhebung von mir. Ich lese, dass ich es geschafft habe, eine solche Situation zu schaffen. Eine, bei der der Mount-Task, der als Root ausgeführt wird, nicht die Berechtigung hat, den Ordner aufzulisten, und Overlayfs dem Benutzer daher den Zugriff auf den Ordner verweigert.

Wenn wir das Overlayfs als Benutzer mounten würden, der auf die Dateien zugreifen darf, also nicht Root ist, sodass die UID nicht gequetscht wird, können wir dann vielleicht das Verzeichnis auflisten und eine Datei darin erstellen?

$ unshare --mount --map-root-user
# mount -t overlay overlay -o lowerdir=/mnt/nfs-share/,upperdir=/tmp/overlay/upper/,workdir=/tmp/overlay/work/ /mnt/overlay/
# ls -la /mnt/overlay/
totalt 28K
drwxrwxr-x 1 root   root    4,0K sep  6 14:08 .
drwxr-xr-x 7 nobody nogroup 4,0K sep  6 14:09 ..
drwx------ 2 nobody nogroup  16K sep  6 13:04 lost+found
drwxr-s--- 2 root   root    4,0K sep  6 14:14 rovanion
# touch /mnt/overlay/rovanion/hi-from-overlay

Und das können wir! Und die Datei existiert nur im Overlay.

$ ls /mnt/ext4-file/rovanion/
hi-from-ext4
$ ls /tmp/overlay/upper/rovanion/
hi-from-overlay

Diese Lösung bringt jedoch ihre eigenen interessanten Implikationen mit sich. Jetzt müssen wir auf unseren nicht 100 % vertrauenswürdigen Maschinen Benutzernamensräume aktiviert haben und befinden uns plötzlich in einem Bereich, in dem unsere UID 0 zu sein scheint, aber für die Außenwelt unserer normalen Benutzer-ID zugeordnet ist. unshare --mountOhne --map-root-usergeht es leider nicht.