Como funcionam os IDs de usuário reais e eficazes?


13

Quando um usuário normal deseja alterar o arquivo passwd, o usuário por setuid recebe o acesso efetivo do usuário. O usuário se torna root temporariamente e pode editar a senha.

No entanto, você só pode editar sua senha corretamente, e nem todo mundo? No entanto, seu acesso efetivo ao usuário é raiz. Então, por que você não tem permissão para alterar outras senhas além das suas?

Quando você executa um programa com setuid, o que significa realmente quando um usuário efetivo é root, mas o ID do usuário real ainda é o seu nome?

Respostas:


13

Você não pode alterar outras senhas porque o programa não permitirá. O programa tem permissões de sistema para alterar qualquer senha que desejar, porque está sendo executado como root, mas o programa foi projetado especificamente para não fornecer ao usuário nenhuma maneira de fazê-lo usar essas permissões.

Não é bem que o usuário se torne root temporariamente, é que o programa confiável seja executado com permissões de root. Obviamente, apenas os programas projetados especificamente para limitar os usuários a fazer apenas o que devem ter permissão para fazê-lo com segurança.


Então, no caso de eu abrir um shell, definindo o uid como 0 (usando setreuid), para que o uid efetivo seja raiz, mas o uid real ainda seja eu. Como eu não acho que o shell especificamente tenha algo embutido que me impeça, significa que eu tenho acesso a todo o sistema?
starcorn

Eu me pergunto no contexto da técnica de ataque de quebra de pilha. Onde hackers mal-intencionados abrem um shell com nível de superusuário.
starcorn

@starcron: Sim. De fato, alguns ataques são demonstrados, mostrando como usar esse ataque para criar um shell raiz setuid.
David Schwartz

2

Você só pode alterar apenas sua senha, apesar de ter um ID de usuário eficaz como root, porque no momento da alteração da senha, o ID de usuário real é verificado e não o ID de usuário efetivo. Você pode alterar apenas o ID do usuário efetivo e não o ID do usuário real.
Somente o usuário root pode alterar o ID do usuário real para executar o programa como usuário não privilegiado. O ID do usuário real não pode ser alterado, pois é definido no momento do início da sessão.
É por isso que apenas sua senha pode ser alterada, pois o ID do usuário real não é alterado (pois ainda é sua, não é raiz).


0

Um hack inicial no Unix foi criar um link simbólico para um script shell setuid e chamá-lo -i. Isso faz com que o script seja chamado como o sh -iqual, em vez de executar o script chamado -icomo pretendido, lança um shell interativo, que fornece todos os poderes. O ID do usuário eficaz pode ser usado para modificar o passwdarquivo para qualquer usuário ou raiz. A melhor maneira de evitar isso é usar o SELinux para impedir que scripts ou programas confiáveis ​​sejam modificados fora da área que o SELinux permite que eles executem.

Outra técnica é ter um bit imutável em arquivos importantes que um conjunto não pode ser modificado nem mesmo pelo usuário root (exceto no modo de usuário único)

Como root, você pode convidar os usuários a fazer logon no sistema sem uma senha e aparecer como qualquer usuário, mas os processos com privilégios normais se esforçam muito para impedir que isso aconteça.

Se você usar algum tipo de sistema de arquivamento em rede, o usuário root será tratado como ninguém naquele espaço no arquivo, em vez de root, o que permite que computadores não confiáveis ​​ingressem em uma rede confiável, como um campus universitário.


0

Você só pode alterar sua senha, porque o programa set-password, embora tenha o poder de fazer qualquer coisa, está programado para alterar apenas senhas. Ele verificará o ID do usuário real, para decidir qual senha alterar.

Como você não pode alterar sua identificação de usuário real, mesmo chamando um programa set-uid, o programa pode usá-lo para implementar a segurança. O sistema operacional renuncia à segurança do programa raiz set uid.

Nota: o programa raiz set uid também pode alterar o ID do usuário real (mas isso não é útil neste caso de uso).

Aviso: definir uid root é considerado prejudicial (muito menos que o ideal). Devemos usar recursos hoje em dia (consulte Quais são as diferentes maneiras de definir permissões de arquivo etc. no gnu / linux e http://man7.org/linux/man-pages/man7/capabilities.7.html )

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.