Come impedire a chgrp di cancellare "bit setuid"?

Abbiamo immagini Linux basate su RH; su cui devo "applicare" alcuni "archivi speciali" per aggiornarli all'ultima versione di sviluppo del nostro prodotto.

La persona che ha creato l'archivio ha capito che nella nostra immagine di base, alcune autorizzazioni sono sbagliate; così ci hanno detto di correre

sudo chgrp -R nobody /whatever

Lo abbiamo fatto; e più tardi, quando la nostra applicazione è in esecuzione, sono emersi problemi oscuri.

Quello che ho trovato più tardi: la chiamata a chgrp sarà cancellare le informazioni setuid po 'sui nostri binari all'interno di / qualcosa.

E il vero problema è: alcuni dei nostri binari devono avere quel bit setuid impostato per funzionare correttamente.

Per farla breve: c'è un modo per eseguire quel comando "chgrp" senza uccidere i miei bit setuid?

Ho appena eseguito il seguente sul mio Ubuntu locale; portando allo stesso risultato:

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

-> mi mostra il nome del file con sfondo rosso -> quindi, sì, setuid

chgrp -R myuser .
ls -al blub 

-> mi mostra il nome del file senza sfondo rosso -> setuid è sparito

Se vuoi implementare il tuo chgrp -R nobody /whatevermantenendo il bit setuid puoi usare questi due findcomandi

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

L' find ... -perm 04000opzione raccoglie i file con il bit setuid impostato. Il primo comando quindi applica chgrpe quindi a chmodper ripristinare il bit setuid che è stato eliminato. Il secondo si applica chgrpa tutti i file che non hanno un bit setuid.

In ogni caso, non si desidera chiamare chgrpo chmodsu collegamenti simbolici poiché ciò influirebbe invece sui loro obiettivi, quindi il ! -type l.

Cancellare i bit SUID e SGID su chgrp(o chown) è perfettamente ragionevole. È una misura di sicurezza per prevenire problemi di sicurezza. Per SGID (su eseguibili, presumo) significa eseguire questo programma con un gruppo effettivo del proprietario del gruppo .

Se cambi il proprietario del gruppo, in termini di sicurezza e controllo degli accessi questo è qualcosa di completamente diverso, cioè invece di funzionare con un gruppo efficace uvwil programma ora funziona con un gruppo efficace xyz.

Pertanto, è necessario ripristinare esplicitamente il bit SUID o SGID al cambio di proprietà.

Addendum: sull'affermazione che chgrp (o chown) dovrebbe cancellare solo SGID (o SUID, resp.)

Inserendo chowno chgrpmodificando le impostazioni di sicurezza per un eseguibile, questo è un motivo sufficiente per cancellare qualsiasi privilegio che eleva gli attributi. Il potere di Unix deriva dalla semplicità concettuale e la sicurezza di Unix è già piuttosto complicata. A tal fine, la rimozione di SUID e SGID in caso di modifica della proprietà è semplicemente una rete di sicurezza - dopotutto, nella storia di Unix / Linux c'erano alcune vulnerabilità dovute a impostazioni SUID o SGID errate.

Quindi non esiste un motivo più profondo per cui Unix si comporti in questo modo, è solo una decisione conservativa di progettazione.

La cancellazione del bit setuid, setgid(almeno su Linux) su non-directory viene fatta dal kernel al momento della chown()chiamata di sistema effettuata chgrp, non da chgrpsola. Quindi l'unico modo è ripristinarlo in seguito.

Cancella anche le funzionalità di sicurezza.

Quindi, su 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
)

Ed esegui (come root):

chown_preseve_sec :newgroup file1 file2...

per cambiare il gruppo mentre si tenta di conservare le autorizzazioni.

Ricorsivamente, potresti fare:

# 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=-

(tutto ciò presuppone che nulla stia altrimenti confondendo i file allo stesso tempo).

Come al solito nell'amministrazione ci sono molti modi per procedere.

La soluzione che ho messo in atto va così:

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