Perché i priv sono tenuti a setgid () per gruppi supplementari

Le varie set*gid()chiamate di sistema richiedono privilegi per cambiare gruppo, tranne in pochissimi casi. La modifica del gruppo primario in uno dei gruppi supplementari dei processi non sembra essere uno di questi, ad esempio i comandi newgrp/ sg, ad esempio, devono elevare i privilegi per passare al gruppo primario.

C'è un motivo per cui setgid()/ setegid()/ setregid()/ setfsgid()non consentono il passaggio a un gruppo supplementare senza priv? In tal caso qual è la ragione?

security group system-calls

— William Hay
fonte

Neanche sicuro. Nota che puoi trasferire un file a uno dei tuoi gruppi supplementari, quindi se hai accesso in scrittura a un'area senza noexec, nosuid, puoi aggirare quella limitazione (creando una copia /usr/bin/envcon il permesso setgid).

— Stéphane Chazelas,

Il comando newgrp lo fa già per me AFAICT ma generare un programma esterno non è sempre quello che si vuole fare.

— William Hay,

Si noti che si newgrp/sgriferisce al database degli account, non all'elenco dei gruppi supplementari del processo.

— Stéphane Chazelas,

Se il tuo gid non è anche nel tuo elenco di ID supplementari, quindi setgid()consentire ti consentirebbe di lasciare l'appartenenza a un gruppo (il che sarebbe un problema di sicurezza), ma poi potresti anche farlo con lo stesso trucco eseguibile setgid di cui sopra, e il tuo gid di solito è anche nella tua lista supplementare ( initgroups(3)prende un argomento gid solo per quello).

— Stéphane Chazelas,

Risposte:

Naturalmente, il puzzle fondamentale qui è che i controlli delle autorizzazioni del filesystem si basano sulla combinazione di (l'UID effettivo e) GID effettivo e GID supplementare. Quindi, dal punto di vista dei controlli delle autorizzazioni dei file, il GID effettivo equivale ai GID supplementari, il che porta alla domanda del PO. (Per inciso: se stiamo parlando di Linux, in realtà è l'UID / GID del filesystem che viene utilizzato nei controlli delle autorizzazioni del filesystem, piuttosto che l'UID e GID effettivi, ma i primi ID hanno quasi sempre gli stessi valori dei secondi ID. )

Quindi, ci devono essere alcuni casi in cui i GID reali / effettivi / salvati non sono equivalenti ai GID supplementari. (Raggruppo insieme i GID reali / effettivi / salvati, poiché le normali regole di autorizzazione set * gid () dicono che un processo senza privilegi può cambiare uno di questi GID allo stesso valore di uno degli altri due.)

E in effetti, ci sono alcuni casi del genere. access (2) effettua i controlli in base all'ID utente reale del processo e all'ID gruppo. Se un utente senza privilegi fosse in grado di modificare l'ID del gruppo reale in modo che fosse uguale a uno dei GID supplementari che non è il GID impostato effettivo o salvato, il comportamento dell'accesso (2) potrebbe essere manipolato.

Ci sono altri casi simili. Vedi la pagina man di Linux mkdir (2) , per un esempio. A seconda che il bit della modalità set-GID sia impostato nella directory principale, un nuovo file creato nella directory prende la proprietà del gruppo dal GID effettivo del processo di creazione. Ancora una volta, se un processo senza privilegi potrebbe cambiare il suo GID effettivo in modo che sia uguale a uno dei suoi GID supplementari, potrebbe manipolare la proprietà del gruppo di nuovi file in modi inaspettati. Commenti simili si applicano per mknod (2) e System V IPC chiama semget (2), shmget (2) e msgget (2).

Esistono anche alcuni casi specifici di Linux in cui i GID set reali / effettivi / salvati non sono equivalenti ai GID supplementari. Vedi process_vm_readv (2) e prlimit (2), per esempio.

— MTK
fonte

Nota: @mtk è l'autore di The Linux Programming Interface .

— Stéphane Chazelas,

Il gid effettivo determina la proprietà del gruppo di nuovi file. Ma poi puoi cambiare quel gruppo in uno dei tuoi gid supplementari in seguito (e anche dare il bit setgid che consente al tuo processo di fare effettivamente un setgid ()). Quindi sembra un po 'una ragione debole.

— Stéphane Chazelas,

@ StéphaneChazelas: d'accordo, è un po 'debole. Su OTOH, questo è ora un processo in due fasi, che (e sto raggiungendo qui) ha il potenziale per razze strane. Ma, a parte quel caso, ci sono gli altri che menziono sopra. Non so quale motivo preciso ci sia stato per questa decisione di progettazione. Forse era access (2), poiché quella è una parte antica dell'API. Molti degli altri sono arrivati più tardi (o sono specifici di Linux) o (presumo) non erano presenti su BSD quando sono stati aggiunti GID supplementari. O, forse, si trattava solo di preservare il comportamento storico; Vedo che hai aggiunto quel punto come risposta.

— mtk,

Penso che il motivo sia principalmente storico. Gruppi supplementari non furono aggiunti fino alla 4.2BSD (circa 1983). Prima di allora, avevi solo i uid e le gid reali ed efficaci.

Il comportamento di setuid / setgid era completamente simmetrico e non aveva motivo di non esserlo. Passeresti l'utente con sue raggrupperesti con sg/ newgrptutti gli eseguibili setuid. Le informazioni sull'appartenenza al gruppo di utenti risiedevano solo nel database degli utenti, non negli attributi dei processi.

E l'interfaccia setuid / setgid non è stata cambiata quando sono state aggiunte gid supplementari.

Tecnicamente ora, se hai accesso in scrittura a un file system (dove l'esecuzione e setuid / setgid non sono disabilitati), puoi comunque impostare il tuo ID utente effettivo o reale su una delle tue gid supplementari (senza dover ricorrere a sg/ newgrpche solo consentire di passare a gruppi definiti nel database degli utenti, che non è necessariamente uguale all'elenco delle gid supplementari del processo).

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

E dopo l'esecuzione env, il tuo egid passa a any-sup-group.

— Stéphane Chazelas
fonte