Como funcionam os componentes internos do sudo?

Question

Como o sudo funciona internamente? Como é possível que ele possa se tornar root sem ter a senha root, ao contrário de su ? Quais syscalls, etc. estão envolvidos no processo? Não é uma lacuna de segurança no Linux (por exemplo, por que não consegui compilar um sudo com patchs muito bom que acabou de fazer o que o sudo regular fez, mas não pediu a senha do usuário não privilegiado)?

Li login e su internals . Eu também li Como o sudo se destina a ser usado? mas apesar do título, eles lida principalmente com as diferenças entre su e sudo .

    

Answer 1

Se você der uma olhada no executável sudo :

$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun  3  2011 /usr/bin/sudo

Você perceberá que ele transporta os bits de permissão ---s--x--x . Estes podem ser divididos da seguinte forma:

-|--s|--x|--x
-      - first dash denotes if a directory or a file ("d" = dir, "-" = file)  
--s    - only the setuid bit is enabled for user who owns file
--x    - only the group execute bit is enabled
--x    - only the other execute bit is enabled

Assim, quando um programa tem seu bit setuid habilitado (também chamado de SUID), significa que quando alguém executar este programa, ele será executado com as credenciais do usuário que possui o arquivo, também conhecido como. root neste caso.

Exemplo

Se eu executar o seguinte comando como usuário saml:

$ whoami
saml

$ sudo su -
[sudo] password for saml: 

Você notará que a execução de sudo está sendo executada como root:

$ ps -eaf|grep sudo
root     20399  2353  0 05:07 pts/13   00:00:00 sudo su -

mecanismo setuid

Se você está curioso para saber como o SUID funciona, dê uma olhada em man setuid . Aqui está um trecho da página man que explica melhor do que eu poderia:

setuid() sets the effective user ID of the calling process. If the effective UID of the caller is root, the real UID and saved set-user-ID are also set. Under Linux, setuid() is implemented like the POSIX version with the _POSIX_SAVED_IDS feature. This allows a set-user-ID (other than root) program to drop all of its user privileges, do some un-privileged work, and then reengage the original effective user ID in a secure manner.

If the user is root or the program is set-user-ID-root, special care must be taken. The setuid() function checks the effective user ID of the caller and if it is the superuser, all process-related user ID's are set to uid. After this has occurred, it is impossible for the program to regain root privileges.

O conceito chave aqui é que os programas têm um ID do usuário (UID) real e um efetivo (EUID). Setuid está definindo o ID do usuário efetivo (EUID) quando este bit está habilitado.

Portanto, do ponto de vista do kernel, sabemos que no nosso exemplo, saml ainda é o proprietário original (UID), mas o EUID foi definido com quem quer que seja o proprietário do executável.

setgid

Eu também devo mencionar que quando estamos quebrando as permissões no comando sudo, o segundo grupo de bits era para permissões de grupo. Os bits de grupo também tem algo semelhante a setuid chamado set group id (também conhecido como setgid, SGID). Isso faz a mesma coisa que o SUID, exceto que ele executa o processo com as credenciais do grupo em vez das credenciais do proprietário.

Referências

• página da Wikipédia setuid
• página do manual setuid

Answer 2

O binário real sudo é root setuid , e você não pode apenas criar arquivos que estão definidos desta maneira.

setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)[1] are Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group respectively and to change behaviour in directories.

    

Answer 3

Para responder a parte sobre syscalls que ninguém parece ter tocado, um dos importantes syscalls é setresuid () ou setresgid (). Eu tenho certeza que existem outros, mas estes 2 parecem bastante específicos para setuid / sudo.