por que precisamos da permissão SUID? [fechadas]

Question

Por favor, leia esta longa introdução para entender a minha preocupação com a necessidade da permissão SUID para arquivo binário executável.

• Um processo no Linux usa seu EUID para conhecer o ID do usuário de si mesmo.
• A permissão deste usuário é usada para decidir como esse processo interage com outros arquivos (por exemplo, se esse processo pode gravar em um arquivo)

Considere o cenário com a alteração da senha por meio de /usr/bin/passwd

Linux da vida real

• As senhas são armazenadas em /etc/shadow . Este arquivo pertence a root com permissão ( rw------- )
• Se $passwd tiver permissão rwx--x--x , isso significa que somente o root pode alterar a lógica do programa passwd .
• Quando userA executa o programa, um processo passwd começa com RUID = EUID = userA

O resultado é: o programa será executado. Um passwd processo é iniciado, mas não poderá alterar a senha, pois seu EUID é userA e userA não pode gravar em /etc/shadow .

É quando a necessidade de permissão SUID chega. O SUID permite definir o EUID de um processo após a execução de um binário para criar esse processo. o EUID será definido para o proprietário desse arquivo binário.

• Definir a permissão SUID para o proprietário de /usr/bin/passwd faz EUID de qualquer passwd processo iniciado por qualquer usuário que tenha EUID de root
• Como root pode gravar em /etc/shadow , qualquer usuário pode usar o programa passwd para iniciar um passwd processo que pode fazer alterações em /etc/shadow

There is SUID permission because in Linux, EUID of a process is not hard set to the owner of the executable binary file (which when run, will create that process)

Meu Linux ideal

No need for SUID permission. If executable file binA is created (and owned) by userA, any users who can execute binA will create a process with EUID = userA.

No contexto do cenário de alteração de senha, a lógica dessa ideia é a seguinte:

• root é o proprietário de /usr/bin/passwd e somente root pode alterar sua lógica.
• A lógica dentro de /usr/bin/passwd permite que um usuário altere sua senha apenas e não outras.
• Outros usuários não podem modificar /usr/bin/passwd , somente raiz pode.
• /etc/shadow só pode ser escrito por root

O resultado é: Um usuário não privilegiado userA pode executar $passwd . Ele criará um passwd process . Este processo tem EUID = root para que ele possa gravar no arquivo shadow .

Com essa teoria, podemos alcançar: todos podem alterar sua própria senha (e apenas sua própria senha) sem permissão SUID .

    

Answer 1

Ambos os seus exemplos explicam como funciona o setuid. No entanto, no seu "Linux ideal", cada executável começaria com o EUID do proprietário do executável, o que tornaria todos os executáveis no seu sistema um executável setuid.

Este seria claramente causar uma série de problemas, para mencionar alguns: cada raiz de propriedade executável precisa fazer verificações UID e chamá setuid() para definir processo de EUID volta para non-root se o programa não deve ter qualquer privilégios adicionais; os usuários não podem disponibilizar executáveis para outros usuários, pois o processo seria executado com o EUID errado; erros de configuração e práticas ruins teriam conseqüências críticas (como chmod 777 agora também permitiria o acesso a quaisquer arquivos pertencentes ao usuário). E estes são mais.

Permissões normais sem binários setuid precisam de algum outro mecanismo para permitir que usuários sem privilégios façam operações privilegiadas. Os binários setuid permitem tal elevação de privilégio e o controle de acesso é implementado na lógica do programa.

    

Answer 2

A resposta marcada respondeu perfeitamente a minha pergunta. O que eu coloco aqui é a lógica extra que é útil para explicar a existência da permissão SUID em relação ao cenário de alteração de senha.

1. No Linux, os arquivos bin executáveis devem ser executados por diferentes usuários.

   For example, /usr/bin/nano is a bin for a text editor, it makes sense that this same executable bin file can be executed by different users (why make copies of the same bin file to each user's home filesystem?)

2. Mesmo que muitos usuários possam usar o mesmo arquivo bin, o processo iniciado por esse arquivo bin deve ter permissões diferentes em um arquivo.

   For example, userA and userB should both be able to create two nano processes by executing the same /usr/bin/nano bin file. However, userA's nano process should allow userA to modify his own files and only his own files and vice versa.

This calls for a mechanism by which a process should apply the same permission that the user who started that process has on a file to that file (instead of the permission of the user who owns the executable bin file which was executed to create the process).

No Linux, cada processo tem o RUID . O RUID é o id do usuário que inicia esse processo. Por essa lógica, o RUID de um processo deve ser o usuário cuja permissão em um arquivo é usada por esse processo (por exemplo, um processo decide o que ele pode fazer com um arquivo baseado em seu RUID usuário pode fazer para esse arquivo).

No entanto, no caso de alterar a senha, o RUID sozinho não é suficiente porque:

1. O arquivo /etc/shadow não pode ser modificado por ninguém, mas root .
2. Qualquer usuário que queira alterar a senha precisa fazer isso através da execução de /usr/bin/passwd arquivo bin executável. A lógica deste programa garante que um usuário desprivilegiado possa alterar sua senha e apenas sua senha.
3. Nenhum usuário, exceto o root, pode alterar essa lógica, pois somente o root pode gravar nesse arquivo bin.
4. Se userA executar /usr/bin/passwd , ele iniciará um passwd processo cujo RUID é userA .
5. No entanto, como userA não tem permissão para gravar em /etc/shadow , o passwd processo iniciado não pode gravar nesse arquivo também.

This calls for a mechanism by which a process decides its permissions to a file based on another user's permissions on that file (instead of the permissions of the user who started the process).

No Linux, a permissão que um processo tem em um arquivo é retirada da permissão que o EUID tem nesse arquivo.

Com EUID , root agora pode usar permissão SUID para permitir que userA inicie um passwd < strong> process que tem o EUID definido como root . Isso efetivamente permite que o passwd processo iniciado por userA modifique o arquivo /etc/shadow .