Was hier passiert, ist, dass Ihr "Unshare" -Prozess keinen Zugriff zum Schreiben in die setgroups(und uid_maps, gid_maps) Dateien im externen Benutzernamensraum hat.
In diesem Namespace befinden sich die Pseudodateien im /proc/<PID>Root-Besitz, und als ob Ihre effektive UID immer noch die Ihres eigenen Benutzers ist, haben Sie keinen Zugriff auf das Schreiben in diese Dateien.
Sie können dies einfach visualisieren, indem Sie einen Prozess im Hintergrund ausführen (z. B. sleep) und die Berechtigungen der setgroupsDatei überprüfen, während sie ausgeführt wird ( uid_mapsund gid_mapssich genauso verhalten).
Erstens mit einer Binärdatei, die keine zusätzlichen Funktionen hat:
$ cp /usr/bin/sleep .
$ ./sleep 10 &
[1] 11209
$ ls -l /proc/11209/setgroups
-rw-r--r--. 1 myuser myuser 0 Jul 31 12:33 /proc/11209/setgroups
[1]+ Done ./sleep 10
$
Fügen wir dann einige Dateifunktionen hinzu und sehen, wie sich der Besitz ändert:
$ sudo setcap cap_net_bind_service=ep sleep
$ ./sleep 10 &
[1] 11220
$ ls -l /proc/11220/setgroups
-rw-r--r--. 1 root root 0 Jul 31 12:34 /proc/11220/setgroups
[1]+ Done ./sleep 10
$
Der Besitz der Dateien in /proc/<PID>wird durch das Flag "dumpable" im Linux-Kernel gesteuert, mit dem verhindert wird, dass Informationen von einem privilegierten Prozess an einen nicht privilegierten Benutzer verloren gehen.
Und wenn man bedenkt, dass Sie unsharemit zusätzlichen Funktionen arbeiten, aber immer noch eine nicht-root- effektive UID haben, wird der Schreibzugriff auf diese Pseudodateien, deren Eigentümer root ist, durch die normalen Zugriffskontrollen des Betriebssystems verhindert.
Sie können den Wert des Flags "dumpable" mit dem PR_GET_DUMPABLEBefehl prysl (2) syscall überprüfen .
In der Beschreibung finden PR_SET_DUMPABLESie auch:
Normalerweise wird dieses Flag auf 1 gesetzt. Unter /proc/sys/fs/suid_dumpableden folgenden Umständen wird es jedoch auf den aktuellen Wert in der Datei zurückgesetzt (die standardmäßig den Wert 0 hat):
[...]
- Der Prozess führt (
execve(2)) ein Programm aus, das über Dateifunktionen verfügt (siehe capabilities(7)), jedoch nur, wenn die zulässigen Funktionen die bereits für den Prozess zulässigen überschreiten.
Welches ist genau Ihr Fall, mit einer unshareBinärdatei, die Dateifunktionen hat.
Interessanterweise tritt bei Verwendung einer Root-eigenen Setuid-Binärdatei für unsharenicht genau dieses Problem auf. Ja, es werden die "dumpable" -Flaggen gelöscht und die Dateien im /proc/<PID>Besitz von root. Wenn Sie jedoch berücksichtigen, dass Ihre effektive UID auch Root ist, wenn Sie eine Setuid-Binärdatei ausführen , wird der Zugriff zugelassen.
In diesem Fall unsharestoßen Sie auf ein anderes Problem, das damit zu tun hat, dass die Logik dieses bestimmte Setup nicht verarbeiten kann (wahrscheinlich etwas damit zu tun, dass die effektive UID und die tatsächliche UID nicht übereinstimmen):
$ cp /usr/bin/unshare .
$ sudo setcap -r unshare
$ sudo chown root:root unshare
$ sudo chmod 4711 unshare
$ ./unshare -r
-bash: cannot set uid to 65534: effective uid 0: Invalid argument
-bash-4.4$
Beachten Sie auch, dass das Löschen des Flags "dumpable" durch Ausführen einer Binärdatei mit festgelegten Dateifunktionen ausgelöst wurde. Wenn Sie zusätzliche Funktionen auf andere Weise erhalten, treten diese Probleme möglicherweise nicht auf. Die Verwendung von "Umgebungs" -Funktionen ist beispielsweise eine gute Möglichkeit, zusätzliche Funktionen außerhalb des Namespace zu erhalten, ohne dass beim Aufheben der Freigabe in einen neuen Benutzernamensraum Probleme auftreten.
(Leider gibt es noch nicht viele Tools für Umgebungsfunktionen. libcapNur Schiffe werden in der neuesten Version 2.25 unterstützt, die derzeit in den meisten Distributionen ausgeliefert wird. Sie capshist ziemlich niedrig, daher ist es nicht so einfach, sie zu erhalten Recht auch nicht . sehen Sie hier Informationen zur Verwendung neuesten capshUmgebungs Funktionen hinzuzufügen. ich habe auch versucht systemd-run, konnte aber nicht wirklich Umgebungs Fähigkeiten dort entweder einrichten bekommen verwalten. auch immer, etwas für Sie zu schauen, wenn Sie tun müssen , Fähigkeiten, nicht Root User & User Namespaces zusammen!)