☰

Wie verhindert man, dass chgrp das „Setuid-Bit“ löscht?

tag-icon • tag-icon linux setuid chgrp
Wie verhindert man, dass chgrp das „Setuid-Bit“ löscht?

Wir haben RH-basierte Linux-Images, auf die ich einige „spezielle Archive“ „anwenden“ muss, um sie auf die neueste Entwicklungsversion unseres Produkts zu aktualisieren.

Die Person, die das Archiv erstellt hat, hat festgestellt, dass in unserem Basis-Image einige Berechtigungen falsch sind. Daher wurde uns gesagt, wir sollten

sudo chgrp -R nobody /whatever

Das haben wir getan. Später, als unsere Anwendung lief, traten obskure Probleme auf.

Was ich später fand: der Aufruf anchgrpWilleklardie Setuid-Bit-Informationen zu unseren Binärdateien innerhalb von /wasauchimmer.

Und das eigentliche Problem ist: einige unserer BinärdateienmussDamit die Funktion ordnungsgemäß funktioniert, muss das Setuid-Bit gesetzt sein.

Lange Rede, kurzer Sinn: Gibt es eine Möglichkeit, den Befehl „chgrp“ auszuführen?ohnemeine Setuid-Bits töten?

Ich habe gerade Folgendes auf meinem lokalen Ubuntu ausgeführt; mit dem gleichen Ergebnis:

mkdir sticky
cd sticky/
touch blub
chmod 4755 blub 
ls -al blub

--> zeigt mir den Dateinamen mit rotem Hintergrund --> also, ja, setuid

chgrp -R myuser .
ls -al blub

--> zeigt mir den Dateinamen ohne roten Hintergrund --> setuid ist weg

Antwort1

Wenn Sie Ihre Implementierung chgrp -R nobody /whateverunter Beibehaltung des Setuid-Bits durchführen möchten, können Sie diese beiden findBefehle verwenden

find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
                                      -exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +

Die find ... -perm 04000Option wählt Dateien aus, bei denen das Setuid-Bit gesetzt ist. Der erste Befehl wendet dann den chgrpund dann ein an chmod, um das entfernte Setuid-Bit wiederherzustellen. Der zweite Befehl gilt chgrpfür alle Dateien, die kein Setuid-Bit haben.

Auf keinen Fall möchten Sie chgrpoder chmodauf symbolischen Links aufrufen, da sich dies stattdessen auf deren Ziele auswirken würde, daher das ! -type l.

Antwort2

Das Löschen der SUID- und SGID-Bits auf chgrp(oder chown) ist durchaus sinnvoll. Es ist eine Sicherheitsmaßnahme, um Sicherheitsproblemen vorzubeugen. Für SGID (auf ausführbaren Dateien, nehme ich an) bedeutetFühren Sie dieses Programm mit der effektiven Gruppe des Gruppenbesitzers aus.

Wenn Sie den Gruppenbesitzer ändern, dann ist das aus Sicherheits- und Zugriffssteuerungssicht etwas völlig anderes, d. h. statt mit der effektiven Gruppe uvwwird das Programm nun mit der effektiven Gruppe ausgeführt xyz.

Daher müssen Sie das SUID- oder SGID-Bit bei einem Eigentümerwechsel explizit wiederherstellen.

Nachtrag: Zur Behauptung, dass chgrp (bzw. chown) nur SGID (bzw. SUID) löschen soll

Durch chowning oder chgrping ändern Sie die Sicherheitseinstellungen für eine ausführbare Datei, und das ist ein ausreichender Grund, alle berechtigungserhöhenden Attribute zu löschen. Die Stärke von Unix beruht auf seiner konzeptionellen Einfachheit, und die Unix-Sicherheit ist bereits recht knifflig. Aus diesem Grund ist das Entfernen von SUID und SGID bei jedem Eigentümerwechsel lediglich ein Sicherheitsnetz – schließlich gab es in der Geschichte von Unix/Linux einige Sicherheitslücken aufgrund fehlgeleiteter SUID- oder SGID-Einstellungen.

Es gibt also keinen tieferen Grund, warum sich Unix so verhält, es ist lediglich eine konservative Designentscheidung.

Antwort3

Das Löschen des setuid, setgid-Bits (zumindest unter Linux) bei Nicht-Verzeichnissen wird vom Kernel beim chown()Systemaufruf von durchgeführt chgrp, nicht von chgrpihm selbst. Die einzige Möglichkeit besteht also darin, es anschließend wiederherzustellen.

Außerdem werden dadurch die Sicherheitsfunktionen gelöscht.

Also, unter GNU Linux:

chown_preserve_sec() (
  newowner=${1?}; shift
  for file do
    perms=$(stat -Lc %a -- "$file") || continue
    cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
    chown -- "$newowner" "$file" || continue
    [ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
    chmod -- "$perms" "$file"
  done
)

Und führe aus (als root):

chown_preseve_sec :newgroup file1 file2...

um die Gruppe zu ändern und gleichzeitig zu versuchen, die Berechtigungen beizubehalten.

Rekursiv könnten Sie Folgendes tun:

# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)

chgrp -RP nobody .

# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z  "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-

(das alles unter der Annahme, dass die Dateien gleichzeitig nicht anderweitig durcheinander geraten).

Antwort4

Wie immer gibt es in der Verwaltung viele Möglichkeiten.

Die von mir implementierte Lösung sieht folgendermaßen aus:

cd /home/me
getfacl -R /whatever > whatever-permissions.org 2> /dev/null

# A) change lines starting with      # group: root
# to                                 # group: whatineed
sed 's/^# group: root/# group: whatineed/g' whatever-permissions.org > whatever-permissions.new

# B) change lines with               group::x.y
# to                                 group::xwy
# (where x, y mean: whatever was there before)
sed 's/^group::\(.\).\(.\)/group::\1w\2/g' whatever-permissions.new > whatever-permissions.new

cd /
setfacl --restore /home/me/whatever-permissions.new

verwandte Informationen