Come funzionano le autorizzazioni Linux quando un processo è in esecuzione come gruppo specifico?

Questo è qualcosa su cui non sono stato in grado di trovare molte informazioni, quindi qualsiasi aiuto sarebbe apprezzato.

La mia comprensione è così. Prendi il seguente file:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

L'utente philnon può accedere a questo file:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

Se philviene aggiunto al admgruppo, può:

root@server:~# adduser phil adm
Adding user `phil' to group `adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

Se, tuttavia, viene avviato un processo mentre si imposta esplicitamente user:groupsu phil:philesso, non è possibile leggere il file. Il processo è iniziato in questo modo:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

Se il processo viene avviato come phil:adm, può leggere il file:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

Quindi la domanda è davvero:

Cosa c'è di speciale nell'esecuzione di un processo con una specifica combinazione utente / gruppo che impedisce al processo di accedere ai file di proprietà di gruppi supplementari di quell'utente e c'è un modo per aggirare questo?

Un processo viene eseguito con un uid ang a gid. Entrambi hanno le autorizzazioni assegnate a loro. È possibile chiamare chroot con un userspec di un utente e di un gruppo, dove in realtà l'utente non appartiene a quel gruppo. Il processo verrebbe quindi eseguito con l'utente uid e il gruppo dato gid.

Vedi un esempio Ho un utente chiamato usered è nel gruppo student:

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

Ho un file come segue:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

Non può leggerlo:

user@host:~$ cat file
cat: file: Permission denied 

Ora, posso eseguire il catprocesso nel contesto dell'utente userE del gruppo root. Ora, il processo cat ha le autorizzazioni necessarie:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

È interessante vedere cosa iddice:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Hm, ma l'utente usernon fa parte di quel gruppo ( root). Da dove idvengono le sue informazioni? Se chiamato senza argomento, idutilizza le chiamate di sistema getuid(), getgid()e getgroups(). Quindi idviene stampato il contesto di processo di se stesso. Quel contesto con cui siamo cambiati --userspec.

Quando viene chiamato con un argomento, iddetermina solo le assegnazioni di gruppo dell'utente:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

Alla tua domanda:

Cosa c'è di speciale nell'esecuzione di un processo con una specifica combinazione utente / gruppo che impedisce al processo di accedere ai file di proprietà di gruppi supplementari di quell'utente e c'è un modo per aggirare questo?

È possibile impostare il contesto del processo di sicurezza necessario per risolvere qualsiasi attività che il processo deve svolgere. Ogni processo ha un set di uid e gid in base al quale viene eseguito. Normalmente il processo "prende" gli utenti chiamanti uid e gid come suo contesto. Con "take" intendo il kernel, altrimenti sarebbe un problema di sicurezza.

Quindi, in realtà non è l'utente, che non ha le autorizzazioni per leggere il file, è il processo 'Permissions ( cat). Ma il processo viene eseguito con l'uid / gid dell'utente chiamante.

Quindi non devi essere in un gruppo specifico per eseguire un processo con il tuo uid e il gid di quel gruppo.

L'uso --userspecdell'opzione on chrootspecifica l'utente e un singolo gruppo da utilizzare durante l'esecuzione di chroot. Per definire gruppi supplementari è necessario utilizzare anche l' --groupsopzione.

Per impostazione predefinita, i processi ereditano i gruppi primari e supplementari dell'utente che li esegue, ma utilizzando --userspecstai dicendo chmoddi sovrascrivere quello usando il singolo gruppo specificato.

La documentazione dettagliata delle autorizzazioni in Linux è disponibile nella credentials(7)manpage.

Quando accedi a Linux, il processo di accesso¹ - dopo aver verificato che puoi accedere come phil - ottiene l'uid di phil e i gruppi a cui appartiene, impostandoli come un processo che viene quindi avviato come shell. Il gruppo uid, gid e supplementare sono di proprietà del processo.

Qualsiasi programma successivo avviato dopo, discende da quella shell e riceve semplicemente una copia di tali credenziali. * Questo spiega perché la modifica dei diritti dell'utente non influisce sui processi in esecuzione. Tuttavia, le modifiche verranno rilevate al prossimo accesso.

* L'eccezione sono i programmi i cui bit setuid o setgid sono impostati, che avranno un diverso ID utente effettivo . Questo è usato ad esempio in su (1) in modo che possa essere eseguito con rootprivilegi anche se eseguito da phil.

Dopo aver aggiunto philal admgruppo, potrebbe scappare su phile, correndo sucome root, verificherà che in effetti fornisce la password di Phil e poi lo inserisce in una shell con i gruppi uid, gid e supplementari a cui appartiene Phil. E poiché ciò avviene dopo aver aggiunto l'utente al gruppo, quella shell sarebbe già nel admgruppo.

Non considero chroot (1) il programma più adatto per l' esecuzione come un utente diverso , ma sicuramente fa il lavoro. Il parametro lo --userspec phil:philfa funzionare con l'uid di phile il gid di phil. Nessun gruppo aggiuntivo è impostato (per quello che forniresti --groups). Pertanto, il processo figlio non è nel admgruppo.

Un modo più normale per eseguire il processo come sarebbe Phil su phil -c "process". Man mano che sucarica i gruppi uid, gid e supplementari dalle informazioni del database utente, processavranno le stesse credenziali dell'utente attualmente.

¹ Questo può essere login (1) , sshd, su, gdb o altri programmi. Inoltre, è probabilmente gestito tramite moduli pam.