Como o mecanismo set-user-ID funciona no Unix?

Question

Alguém pode explicar o mecanismo set-user-ID no Unix? Qual foi a lógica por trás dessa decisão de design? Como isso é diferente do mecanismo de id de usuário efetivo?

    

Answer 1

Você pode conhecer as permissões normais de leitura, gravação e execução de arquivos no unix.

No entanto, em muitos aplicativos, esse tipo de estrutura de permissão - por exemplo, dar a um dado usuário permissão total para ler um determinado arquivo, ou nenhuma permissão para ler o arquivo - é muito grosseiro. Por esse motivo, o Unix inclui outro bit de permissão, o set-user-ID bit. Se esse bit for definido para um arquivo executável, sempre que um usuário diferente do proprietário executar o arquivo, esse usuário obterá todos os privilégios de leitura / gravação / execução do proprietário para acessar qualquer um dos outros arquivos do proprietário!

Para definir o bit set-user-ID para um arquivo, digite

 chmod u+s filename

Certifique-se de ter definido a permissão de execução de outros grupos também; Seria bom ter permissão de leitura em grupo, além de outras. Tudo isso pode ser feito com a única declaração

 chmod 4755 filename

Ele também é chamado de UID salvo. Um arquivo que é iniciado com um bit Set-UID ativado, o UID salvo será o UID do proprietário do arquivo. Caso contrário, o UID salvo será o UID real.

O que é uid eficaz?

Esse UID é usado para avaliar os privilégios do processo para executar uma ação específica. O EUID pode ser alterado para Real UID ou Superuser UID se EUID! = 0. Se EUID = 0, pode ser alterado para qualquer coisa.

Exemplo

Um exemplo de tal programa é passwd . Se você listá-lo na íntegra, você verá que ele tem Set-UID bit e o proprietário é "root". Quando um usuário normal, digamos "mtk", executa passwd , ele começa com:

Real-UID = mtk  
Effective-UID = mtk  
Saved-UID = root

Link de referência 1
Relação de referência 2

    

Answer 2

man credentials é uma boa fonte de informação neste caso. Veja também esta quest em SO . Para uma explicação histórica, consulte esta postagem arquivada .

Em vez de chamar "set UID" e "effective UID" um mecanismo, todo o conceito de UIDs deve ser chamado assim. A justificativa para a existência dos vários UIDs são vários problemas com a separação de privilégios. Mesmo usuários regulares (não privilegiados) às vezes precisam fazer coisas (recursos de acesso) que somente usuários privilegiados podem fazer. Para conseguir isso facilmente, os programas podem alterar seus UIDs. Existem 3 tipos destes:

• UID real - o UID que possui um processo

• UID efetivo - o UID no qual um processo é executado no momento - isso determina os recursos reais do processo em qualquer momento específico. Isso também é o que ps mostra no campo USER.

• conjunto de UIDs salvos - espaço reservado usado para alternar entre UIDs reais e efetivos

A necessidade do último surge do fato de que usuários regulares podem apenas mudar entre estes três e nada mais e um programa setuid geralmente precisa saber de alguma forma, quem foi o usuário que o carregou (mais o UID real não deve ser alterado, pois isso criaria uma bagunça ainda maior).

    

Answer 3

A expansão do mtk é boa.

O exemplo passwd é de escalonamento de privilégios - o passwd sempre é executado como root, já que ele deve alterar os arquivos que somente o root tem permissão para alterar. Isso faz com que seja importante que o executável passwd não seja propenso a sobrecargas de buffer, etc, de tal forma que um usuário normal inteligente possa colocá-lo em utilizações para as quais ele não foi planejado.

Outro raciocínio é proteger o usuário da mesma maneira que você pode usar su se você estiver logado como root - para diminuir ou restringir seus privilégios para tarefas específicas, não escalá-los. Por exemplo, se eu tiver permissão para iniciar um serviço daemon que não requeira acesso ao meu material e tenha seu próprio material, que é tudo que ele precisa (por exemplo, um logger), executá-lo suid significa que ele só tem acesso a essas coisas. e não minha ou qualquer outra pessoa.

Observe que é possível definir o programa de forma uid mesmo que o bit suid não esteja definido no executável , no entanto, isso não funcionará para escalonamento. Ou seja, se você é um usuário normal e escreve um programa que define uid em algum momento, esse programa não pode mudar para root. O Apache funciona dessa maneira, eu acredito. Geralmente é iniciado pelo root e tem um processo que então bifurca os filhos que mudam para um usuário não privado (por exemplo, "httpd"). Esses processos filhos são o que o servidor web real funciona.