Ich experimentiere mit Fähigkeiten unter Debian Gnu / Linux.

Ich habe / bin / ping in mein aktuelles Arbeitsverzeichnis kopiert. Wie erwartet funktioniert es nicht, es war ursprünglich setuid root.

Ich gebe dann meinem Ping die minimalen Fähigkeiten (nicht root) durch sudo /sbin/setcap cap_net_raw=ep ./ping, und mein Ping funktioniert wie erwartet.

Dann sudo /sbin/setcap -r ./pingdiese Fähigkeit zu widerrufen. Es funktioniert jetzt nicht wie erwartet.

Ich versuche jetzt, Ping zum Arbeiten zu bringen capsh.

capsh hat keine Privilegien, also muss ich es als root ausführen, dann aber root und damit alle anderen Privilegien löschen.

Ich denke ich brauche auch secure-keep-caps, das ist nicht dokumentiert capsh, steht aber im Capability Manual. Ich habe die Bitnummern von /usr/include/linux/securebits.h. Sie scheinen korrekt zu sein, da die Ausgabe von --printzeigt, dass diese Bits korrekt sind.

Ich habe stundenlang herumgespielt, bis jetzt habe ich das.

sudo /sbin/capsh --keep=1 --secbits=0x10 --caps="cap_net_raw+epi" == --secbits=0x10 --user=${USER} --print -- -c "./ping localhost"

Jedoch pingFehler mit ping: icmp open socket: Operation not permitted, das ist , was passiert , wenn es nicht die Fähigkeit hat. Auch die --printShows Current: =p cap_net_raw+i, das reicht uns nicht e.

sudo /sbin/capsh --caps="cap_net_raw+epi" --print -- -c "./ping localhost"wird die Fähigkeit dazu Current: = cap_net_raw+eiprichtig einstellen , lässt uns aber als root.

Bearbeiten-1

Ich habe es jetzt versucht sudo /sbin/capsh --keep=1 --secbits=0x11 --caps=cap_net_raw+epi --print -- -c "touch zz; ./ping -c1 localhost;"

Dies erzeugt:

touch: cannot touch `zz': Permission denied
ping: icmp open socket: Operation not permitted

Der erste Fehler wird als erwartet, secure-noroot: yes der zweite jedoch nichtCurrent: = cap_net_raw+eip

Bearbeiten-2

Wenn ich das ==vorstelle --print, zeigt es jetzt Current: = cap_net_raw+i, so dass der vorherige Fehler erklärt wird, aber nicht, warum wir beim Wechseln von root die Fähigkeit verlieren, ich dachte, das secure-keep-capssollte das beheben.

Bearbeiten-3

Nach allem, was ich sehen kann, verliere ich Effective (e) und Permitted (p), wenn exec aufgerufen wird. Dies wird erwartet, aber ich dachte, dass Secure-Keep-Caps verhindern sollten, dass sie verloren gehen. Vermisse ich etwas?

Bearbeiten-4

Ich habe mehr recherchiert und das Handbuch erneut gelesen. Es scheint, dass normalerweise eund pFähigkeiten verloren gehen, wenn: Sie vom Benutzer wechseln root(oder anwenden secure-noroot, um root zu einem normalen Benutzer zu machen), dies mit überschrieben werden kann secure-keep-caps; Wenn Sie anrufen exec, ist dies, soweit ich das beurteilen kann, eine Invariante.

Soweit ich das beurteilen kann, funktioniert es laut Handbuch. Soweit ich das beurteilen kann, gibt es keine Möglichkeit, etwas Nützliches damit anzufangen capsh. Soweit ich das beurteilen kann, müssen Sie für die Nutzung von Funktionen: Dateifunktionen verwenden oder über ein funktionsbewusstes Programm verfügen, das keine Funktionen verwendet exec. Daher kein privilegierter Wrapper.

Nun ist meine Frage, was ich vermisse, wofür capsh.

Bearbeiten-5

Ich habe eine Antwort bezüglich der Umgebungsfunktionen hinzugefügt. Möglicherweise capshkann es auch mit vererbten Funktionen verwendet werden, aber um nützlich zu sein, müssen diese in der ausführbaren Datei festgelegt werden. Ich kann nicht sehen, wie capsh etwas Nützliches tun kann, ohne Umgebungsfähigkeiten oder geerbte Fähigkeiten zuzulassen.

Versionen:

• capshvon Paket - libcap2-binVersion1:2.22-1.2
• vor edit-3 habe ich mir das neueste capshvon geholt git://git.debian.org/collab-maint/libcap2.gitund angefangen es zu benutzen.
• uname -a Linux richard-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux User-Land ist 32bit.

Fähigkeiten sind Eigenschaften von Prozessen. Traditionell gibt es drei Sätze:

• Zulässige Funktionen ( p ): Funktionen, die im aktuellen Prozess "aktiviert" werden können.
• Effektive Funktionen ( e ): Funktionen, die derzeit im aktuellen Prozess verwendet werden können.
• Vererbbare Funktionen ( i ): Dateifunktionen, die möglicherweise vererbt werden.

Programme, die als Root ausgeführt werden, verfügen immer über voll zugelassene und effektive Funktionen, sodass das Hinzufügen weiterer Funktionen keine spürbaren Auswirkungen hat. (Der Satz vererbbarer Funktionen ist normalerweise leer.) Wenn setcap cap_net_raw+ep pingSie diese Funktionen standardmäßig für alle Benutzer aktivieren, die dieses Programm ausführen.

Leider sind diese Funktionen an die ausgeführte Datei gebunden und werden nach der Ausführung eines neuen untergeordneten Prozesses nicht beibehalten. In Linux 4.3 wurden Ambient-Funktionen eingeführt , mit denen untergeordnete Prozesse Funktionen übernehmen können. (Siehe auch Transformation von Fähigkeiten während execve () in Fähigkeiten (7) .)

Beachten Sie beim Spielen mit Fähigkeiten die folgenden Fallstricke:

• Wenn Sie den Benutzer von root auf nicht-root ändern, werden die effektiven und zulässigen Funktionen gelöscht (siehe Auswirkungen von Änderungen der Benutzer-ID auf Funktionen in Funktionen (7) ). Sie können die --keep=1Option verwenden capsh, um das Löschen der Sätze zu vermeiden.
• Die eingestellten Umgebungsfunktionen werden gelöscht, wenn die Benutzer- oder Gruppen-IDs geändert werden. Lösung: Fügen Sie die Umgebungsfunktionen hinzu, nachdem Sie die Benutzer-ID geändert haben, aber bevor Sie einen untergeordneten Prozess ausführen.
• Eine Funktion kann nur zu den Umgebungsfunktionen hinzugefügt werden, wenn sie sich bereits in den zulässigen und vererbbaren Funktionen befindet.

Das capshProgramm von libcap 2.25 kann die Umgebungsfunktionen noch nicht ändern, aber spätere Versionen bieten neue Optionen. Beachten Sie, dass die Reihenfolge der Optionen von Bedeutung ist. Beispielverwendung:

sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" \
    --keep=1 --user=nobody --addamb=cap_net_raw -- \
    -c "./ping -c1 127.0.0.1"

Tipp: Sie können die --printOption an einer beliebigen Stelle in der capshBefehlszeile hinzufügen und den aktuellen Status der Funktionen anzeigen.

Hinweis: cap_setpcapwird benötigt, --addambsolange cap_setuid,cap_setgidfür die --userOption benötigt werden .

Die Antwort von Lekensteyn scheint korrekt und vollständig zu sein, aber ich werde versuchen, eine andere Erklärung aus einem anderen Blickwinkel zu liefern, um das Problem hervorzuheben, das durch die Umgebungsfunktionen gelöst wird.

Wenn Sie ausführen sudo capsh --user=<some_user> --Es gibt 2 Systemaufrufe von Interesse, die dazu führen, dass Funktionen neu berechnet (und möglicherweise gelöscht) werden:

1. setuid: Nach man capabilities:

SECBIT_KEEP_CAPS Durch Setzen dieses Flags kann ein Thread mit einer oder mehreren 0-UIDs seine Funktionen beibehalten, wenn er alle seine UIDs auf einen Wert ungleich Null wechselt. Wenn dieses Flag nicht gesetzt ist, führt ein solcher UID-Schalter dazu, dass der Thread alle Funktionen verliert.

Mit anderen Worten, in unserem capshobigen Befehl müssen wir sicherstellen, dass SECBIT_KEEP_CAPS während des setuidSystemaufrufs gesetzt ist. Andernfalls gehen alle Funktionen verloren. Das macht der --keep=1. So, jetzt wird der Befehlsudo capsh --user=<some_user> --keep=1 --

2. execve: Wenn wir die --keep=1Option verwenden, bleiben alle Fähigkeitssätze (effektiv, zulässig, vererbbar) bis zum execveSystemaufruf erhalten. Allerdings werden execvedie Fähigkeiten auch (für Nicht-Root-Benutzer) neu berechnet, und zwar auf nicht so offensichtliche Weise. Kurz gesagt, bevor die Umgebungsfunktionen hinzugefügt werden , kann eine Funktion nach einem execveAufruf in der "erlaubten" Gruppe eines Threads enthalten sein :

   • Die Datei muss diese Fähigkeit in ihrem "erlaubten" Satz haben . Dies kann mit erfolgen setcap cap_net_raw+p /bin/bash. Dadurch wird die gesamte Übung unbrauchbar, da die Fähigkeitssätze des Threads (mit Ausnahme des Begrenzungssatzes) keine Wirkung mehr haben.
   • Sowohl die Datei als auch der Thread müssen diese Fähigkeit in ihren "vererbbaren" Mengen haben . Sie denken vielleicht, dass setcap cap_net_raw+idies der Trick wäre, aber es stellt sich heraus, execvedass die vererbbaren Berechtigungen eines Threads gelöscht werden, wenn sie von nicht privilegierten Benutzern aufgerufen werden (wofür wir uns derzeit bedanken setuid). Es gibt also keine Möglichkeit, diese Bedingung als nicht privilegierter Benutzer zu erfüllen.

Mit den in Linux 4.3 eingeführten Umgebungsfunktionen kann ein Thread seine Funktionen auch nach einem setuidZugriff auf einen nicht privilegierten Benutzer und anschließend auf einen beibehalten execve, ohne sich auf Dateifunktionen verlassen zu müssen.

Möglicherweise ist ein Fehler im Kernel aufgetreten. Es hat einige Diskussionen gegeben:

• https://bugzilla.altlinux.org/show_bug.cgi?id=16694
• http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/5224.html

Ich habe keine Ahnung, ob etwas getan wurde, um es zu beheben.

Versteh mich nicht falsch - das aktuelle Verhalten ist sicher. Aber es ist so sicher, dass es den Dingen im Weg steht, die anscheinend funktionieren sollten.

Edit: Laut http://man7.org/linux/man-pages/man7/capabilities.7.html gibt es einen neuen Capability Set Ambient (seit Linux 4.3). Es sieht so aus, als würde dies das ermöglichen, was benötigt wird.