initgroup()
, a função libc normalmente chamada pelos aplicativos login para definir a lista de grupos suplementares do processo executado em seu nome, adiciona o ID do grupo primário a essa lista.
Caso contrário, isso seria um problema de segurança, pois isso permitiria a você abandonar o acesso a esse grupo criando um executável setgid com um de seus outros grupos e executaria isso para perder seu gid primário ( esse executável teria que chamar setgid()
para o gid real também mudar), o que lhe daria acesso a recursos que foram explicitamente negados acesso ao seu grupo primário, por exemplo.
Exemplo:
$ ls -l file
-rw----r-- 1 root chazelas 7 Dec 12 15:33 file
O acesso foi negado ao meu principal gID:
$ cat file
cat: file: Permission denied
Agora, vamos começar um shell como eu, onde os IDs de grupo suplementares não incluem esse grupo para ver o que poderíamos fazer se login
não adicionasse esse grupo à nossa lista de ID de grupo suplementar:
$ sudo perl -le '$( = $) = "1000 2"; $< = $> = 1000; exec zsh'
$ ps -o rgroup,egroup,supgrp -p $$
RGROUP EGROUP SUPGRP
chazelas chazelas bin
$ id -a
uid=1000(chazelas) gid=1000(chazelas) groups=1000(chazelas),2(bin)
1000 está em gid, egid, mas não na lista de grupos suplementares. Como também sou membro de bin
, posso criar um executável setgid bin
:
$ cp -f /usr/bin/env .
$ chgrp bin env
$ chmod g+s env
$ ./env perl -U -le '$( = $); exec qw(/usr/bin/id -a)'
uid=1000(chazelas) gid=2(bin) groups=2(bin)
Estou usando perl
para chamar setgid()
( $( = $)
). E então perdi a associação do grupo chazelas
. Então:
$ ./env perl -U -le '$( = $); exec qw(cat file)'
secret
Ao adicionar o grupo à lista suplementar, login
garante que você não pode sair dele (pois somente o root pode alterar essa lista e não é afetado pela execução de executáveis do setgid).