setuid - setuid

"SGID" redireciona aqui. Para a empresa que usou brevemente este símbolo de cotação da bolsa, consulte Silicon Graphics .

Os sinalizadores de direitos de acesso Unix setuid e setgid (abreviação de "definir ID do usuário" e "definir ID do grupo") permitem que os usuários executem um executável com as permissões do sistema de arquivos do proprietário ou grupo do executável, respectivamente, e alterem o comportamento nos diretórios. Eles são freqüentemente usados ​​para permitir que os usuários em um sistema de computador executem programas com privilégios temporariamente elevados para executar uma tarefa específica. Embora os privilégios de id de usuário ou id de grupo fornecidos nem sempre sejam elevados, no mínimo eles são específicos.

Os sinalizadores setuide setgidsão necessários para tarefas que requerem privilégios diferentes dos normalmente concedidos ao usuário, como a capacidade de alterar arquivos de sistema ou bancos de dados para alterar sua senha de login. Algumas das tarefas que requerem privilégios adicionais podem não ser imediatamente óbvias, como o pingcomando, que deve enviar e ouvir pacotes de controle em uma interface de rede.

Efeitos

Os sinalizadores setuide setgidtêm efeitos diferentes, dependendo se são aplicados a um arquivo, a um diretório ou arquivo executável binário ou executável não binário. Os sinalizadores setuide setgidtêm efeito apenas em arquivos binários executáveis ​​e não em scripts (por exemplo, Bash, Perl, Python).

Quando definido em um arquivo executável

Quando os atributos setuidou setgidsão definidos em um arquivo executável , qualquer usuário capaz de executar o arquivo executará automaticamente o arquivo com os privilégios do proprietário do arquivo (normalmente root ) e / ou do grupo do arquivo, dependendo dos sinalizadores definidos. Isso permite que o projetista do sistema permita a execução de programas confiáveis ​​que, de outra forma, o usuário não teria permissão para executar. Isso nem sempre é óbvio. Por exemplo, o comando ping pode precisar de acesso a privilégios de rede que um usuário normal não pode acessar; portanto, pode ser fornecido o sinalizador setuid para garantir que um usuário que precise executar ping em outro sistema possa fazê-lo, mesmo que sua própria conta não tenha o privilégio necessário para enviar pacotes.

Por motivos de segurança, o usuário invocação é geralmente proibida pelo sistema de alterar o novo processo de qualquer forma, por exemplo, usando ptrace, LD_LIBRARY_PATHou enviar sinais para ele, para explorar o privilégio elevado, embora os sinais do terminal ainda serão aceitos.

Os bits setuide setgidsão normalmente definidos com o comando chmod, definindo o dígito octal de ordem superior como 4 para setuidou 2 para setgid. " " definirá os bits e (4 + 2 = 6), tornando o arquivo de leitura / gravação / executável para o proprietário (7), e executável pelo grupo (primeiro 1) e outros (segundo 1). Quando um usuário diferente do proprietário executa o arquivo, o processo é executado com permissões de usuário e grupo definidas por seu proprietário. Por exemplo, se o arquivo pertencer a um usuário e grupo , ele será executado independentemente de quem executa o arquivo. chmod 6711 filesetuidsetgidrootwheelroot:wheel

A maioria das implementações do chmodcomando também suporta argumentos simbólicos mais refinados para definir esses bits. O modo de granulação mais fina, de preferência, é mostrado na demonstração abaixo como o " chmod ug+s"

Impacto na segurança

Embora o setuidrecurso seja muito útil em muitos casos, seu uso indevido pode representar um risco de segurança se o setuidatributo for atribuído a programas executáveis que não são cuidadosamente projetados. Devido a possíveis problemas de segurança, muitos sistemas operacionais ignoram o setuidatributo quando aplicado a scripts de shell executáveis .

A presença de setuidexecutáveis ​​explica porque a chrootchamada do sistema não está disponível para usuários não root no Unix. Veja as limitações dechroot para mais detalhes.

Quando definido em um diretório

Definir a setgidpermissão em um diretório (" chmod g+s") faz com que novos arquivos e subdiretórios criados dentro dele herdem seu ID de grupo , em vez do ID de grupo primário do usuário que criou o arquivo (o ID do proprietário nunca é afetado, apenas o ID do grupo) .

  1. Os subdiretórios recém-criados herdam o setgidbit. Portanto, isso permite um espaço de trabalho compartilhado para um grupo sem a inconveniência de exigir que os membros do grupo alterem explicitamente seu grupo atual antes de criar novos arquivos ou diretórios.
  2. afeta apenas o ID de grupo de novos arquivos e subdiretórios criados depois que o setgidbit é definido e não é aplicado a entidades existentes.
  3. não afeta o ID de grupo dos arquivos criados em outro lugar e movidos para o diretório em questão. O arquivo continuará a carregar o ID do grupo que foi afetado quando e onde foi criado.

Definir o setgidbit em subdiretórios existentes deve ser feito manualmente, com um comando comofind /path/to/directory -type d -exec chmod g+s '{}' \;

A setuidpermissão definida em um diretório é ignorada na maioria dos sistemas UNIX e Linux . No entanto, o FreeBSD pode ser configurado para interpretar de setuidmaneira semelhante a setgid, caso em que força todos os arquivos e subdiretórios criados em um diretório a pertencerem ao dono daquele diretório - uma forma simples de herança. Geralmente, isso não é necessário na maioria dos sistemas derivados do BSD , pois, por padrão, os diretórios são tratados como se seu setgidbit estivesse sempre definido, independentemente do valor real. Conforme afirmado em open(2), "Quando um novo arquivo é criado, ele recebe o grupo do diretório que o contém."

Exemplos

Verificando permissões

As permissões de um arquivo podem ser verificadas em formato octal e / ou alfabético com a ferramenta de linha de comando stat 

[ torvalds ~ ] $ stat -c "%a %A" ~/test/
1770 drwxrwx--T

SUID

4701 em um arquivo executável pertencente a 'root' e o grupo 'root'

Um usuário chamado 'thompson' tenta executar o arquivo. A permissão executável para todos os usuários é definida (o '1') para que 'thompson' possa executar o arquivo. O proprietário do arquivo é 'root' e a permissão SUID é definida (o '4') - então o arquivo é executado como 'root'.

A razão pela qual um executável seria executado como 'root' é para que ele possa modificar arquivos específicos que o usuário normalmente não teria permissão para, sem dar ao usuário acesso root completo.

Um uso padrão disso pode ser visto com o /usr/bin/passwdarquivo binário. /usr/bin/passwdprecisa modificar /etc/passwde /etc/shadowque armazena informações de conta e hashes de senha para todos os usuários, e estes só podem ser modificados pelo usuário 'root'.

[ thompson ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd
4701 root:root /usr/bin/passwd

[ thompson ~ ] $ passwd
passwd: Changing password for thompson

O proprietário do processo não é o usuário que executa o arquivo executável, mas o proprietário do arquivo executável

SGID

2770 em um diretório chamado 'music' pertencente ao usuário 'root' e ao grupo 'engenheiros'

Um usuário chamado 'torvalds' que pertence principalmente ao grupo 'torvalds', mas secundariamente ao grupo 'engenheiros', cria um diretório denominado 'eletrônico' no diretório denominado 'música'. A propriedade do grupo do novo diretório denominado 'eletrônico' herda 'engenheiros'. Este é o mesmo ao criar um novo arquivo chamado 'imagine.txt'

Sem o SGID, a propriedade do grupo do novo diretório / arquivo seria 'torvalds', pois esse é o grupo primário de usuários 'torvalds'. 

[ torvalds ~ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds ~ ] $ stat -c "%a %U:%G %n" ./music/
2770 root:engineers ./music/

[ torvalds ~ ] $ mkdir ~/music/electronic

[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/electronic/
torvalds:engineers ./music/electronic/

[ torvalds ~ ] $ echo 'NEW FILE' > ./music/imagine.txt

[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/imagine.txt
torvalds:engineers ./music/imagine.txt

[ torvalds ~ ] $ touch ~/test

[ torvalds ~ ] $ stat -c "%U:%G %n" ~/test
torvalds:torvalds ~/test

Pedaço pegajoso

Veja também: Sticky bit

1770 em um diretório chamado 'videogames' pertencente ao usuário 'torvalds' e ao grupo 'engenheiros'.

Um usuário chamado 'torvalds' cria um arquivo chamado 'tekken' no diretório chamado 'videogames'. Um usuário chamado 'wozniak', que também faz parte do grupo 'engenheiros', tenta excluir o arquivo chamado 'tekken', mas não consegue, pois não é o proprietário.

Sem o sticky bit, 'wozniak' poderia ter excluído o arquivo, porque o diretório chamado 'videogames' permite a leitura e escrita por 'engenheiros'. Um uso padrão disso pode ser visto na /tmppasta. 

[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds /home/shared/ ] $ stat -c "%a  %U:%G  %n" ./videogames/
1770  torvalds:engineers  ./videogames/

[ torvalds /home/shared/ ] $ echo 'NEW FILE' > videogames/tekken

[ torvalds /home/shared/ ] $ su - wozniak
Password:

[ wozniak ~/ ] $ groups wozniak
wozniak : wozniak engineers

[ wozniak ~/ ] $ cd /home/shared/videogames

[ wozniak /home/shared/videogames/ ] $ rm tekken
rm: cannot remove ‘tekken’: Operation not permitted

Sticky bit com SGID

3171 em um diretório chamado 'blog' pertencente ao grupo 'engenheiros' e o usuário 'root'

Um usuário chamado 'torvalds' que pertence principalmente ao grupo 'torvalds', mas secundariamente ao grupo 'engenheiros', cria um arquivo ou diretório chamado 'pensamentos' dentro do diretório 'blog'. Um usuário chamado 'wozniak' que também pertence ao grupo 'engenheiros' não pode excluir, renomear ou mover o arquivo ou diretório chamado 'pensamentos', porque ele não é o proprietário e o sticky bit está definido. No entanto, se 'pensamentos' for um arquivo, 'wozniak' poderá editá-lo.

O bit pegajoso tem a decisão final. Se sticky bit e SGID não tiverem sido definidos, o usuário 'wozniak' pode renomear, mover ou excluir o arquivo chamado 'pensamentos' porque o diretório chamado 'blog' permite leitura e gravação por grupo, e wozniak pertence ao grupo, e o padrão 0002 umask permite que novos arquivos sejam editados por grupo. Sticky bit e SGID podem ser combinados com algo como um umask somente leitura ou um atributo somente acréscimo.

[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds /home/shared/ ] $ stat -c "%a  %U:%G  %n" ./blog/
3171  root:engineers  ./blog/

[ torvalds /home/shared/ ] $ echo 'NEW FILE' > ./blog/thoughts

[ torvalds /home/shared/ ] $ su - wozniak
Password:

[ wozniak ~/ ] $ cd /home/shared/blog

[ wozniak /home/shared/blog/ ] $ groups wozniak
wozniak : wozniak engineers

[ wozniak /home/shared/blog/ ] $ stat -c "%a  %U:%G  %n" ./thoughts
664  torvalds:engineers  ./thoughts

[ wozniak /home/shared/blog/ ] $ rm thoughts
rm: cannot remove ‘thoughts’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ mv thoughts /home/wozniak/
mv: cannot move ‘thoughts’ to ‘/home/wozniak/thoughts’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ mv thoughts pondering
mv: cannot move ‘thoughts’ to ‘pondering’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ echo 'REWRITE!' > thoughts

[ wozniak /home/shared/blog/ ] $ cat thoughts
REWRITE!

Segurança

Os desenvolvedores projetam e implementam programas que usam esse bit em executáveis ​​com cuidado para evitar vulnerabilidades de segurança, incluindo saturações de buffer e injeção de caminho . Ataques de saturação de buffer bem-sucedidos em aplicativos vulneráveis ​​permitem que o invasor execute código arbitrário sob os direitos do processo explorado. No caso de um processo vulnerável usar o setuidbit para ser executado como root, o código será executado com privilégios de root, dando ao invasor acesso root ao sistema no qual o processo vulnerável está sendo executado.

De particular importância no caso de um setuidprocesso é o ambiente do processo. Se o ambiente não for devidamente higienizado por um processo privilegiado, seu comportamento pode ser alterado pelo processo não privilegiado que o iniciou. Por exemplo, GNU libc estava em um ponto vulnerável a um exploit usando setuide uma variável de ambiente que permitia a execução de código de bibliotecas compartilhadas não confiáveis .

História

O setuidbit foi inventado por Dennis Ritchie e incluído em su. Seu empregador, então Bell Telephone Laboratories , solicitou uma patente em 1972; a patente foi concedida em 1979 com o número de patente US 4135240  "Proteção do conteúdo do arquivo de dados". A patente foi posteriormente colocada em domínio público .

Veja também

Referências

links externos