Linux: programas setuid sem permissão de leitura

Question

Tenho notado que em todos os sistemas Linux ArchLinux * , determinados programas setuid vêm com permissões bastante incomuns:

-r-sr-xr-x  root  root  /bin/su*
---s--x--x  root  root  /usr/bin/sudo*

A questão é: por que o conjunto binário sudo é legível apenas para o root? Qual é o sentido disso? Por que não pode ser como su ?

Editar: depois de reinstalar sudo , ele também não tem leitura / gravação.

( * eu poderia jurar que vi o mesmo no Debian. Aparentemente não.)

    

Answer 1

A primeira pergunta que me veio à mente é: Por que o sudo tem permissão de gravação para o root?

Em geral, os programas suidos são bastante perigosos e você deve conceder a eles o menor número de privilégios possível. Você não pode ficar muito mais restritivo do que apenas permissão de execução!

Se você puder ler um arquivo, poderá desmontá-lo. E, se você puder desmontá-lo, poderá procurar falhas de segurança e torná-lo um pouco mais fácil de descobrir vetores de ataque.

sudo é um pouco mais vulnerável a ataques do que su , pois nem sempre é necessário fornecer uma senha para ter acesso privilegiado a alguns recursos (dependendo de como ela está configurada). Isso pode garantir maior segurança.

    

Answer 2

Na minha máquina, Ubuntu 9.04, não há diferença nas permissões.

-rwsr-xr-x 2 root root /usr/bin/sudo
-rwsr-xr-x 1 root root /bin/su

Em sua máquina, ela pode não ter sido legível na tentativa de impedir que as pessoas a usem? Pode ter sido editado de alguma forma? Não há razão para as permissões nos dois arquivos serem diferentes. No Ubuntu, a conta root está bloqueada - você não pode logar como root de qualquer maneira (a menos que você tome ações para ativá-la, obviamente).

Talvez haja diferenças de sistema operacional aqui. Qual sistema operacional você está usando no seu exemplo?

    

Answer 3

Eu questiono sua premissa. Por que sudo deveria ser como su?

su apenas concede privs se você (a) já as tiver ou (b) autenticar para obtê-las.

sudo concede privs baseado em uma base de regra; pode-se dizer, por exemplo, para conceder privs root para 'joe' a qualquer momento que joe perguntar, sem necessidade de senha. "homem sudoers" - é bastante poderoso.

Então o sudo tem a capacidade de fazer coisas que o su não pode fazer.

Poder-se-ia pisar no executável sudo de tal forma que ele sempre concedesse root a qualquer um que pedisse - ignorando o arquivo sudoers e apenas usando um tipo de "hardwiring" interno.

Portanto, faz sentido protegê-lo MAIS do que precisamos proteger o su; faz sentido tornar muito difícil ler ou gravar no próprio executável do sudo.