¿Cómo sudo trabajar internamente? ¿Cómo es posible que pueda convertirse en root sin tener la contraseña de root, a diferencia de su? ? ¿Qué llamadas al sistema, etc. están involucradas en el proceso? ¿No es un agujero de seguridad enorme en Linux (por ejemplo, por qué no pude compilar un sudo con muchos parches? que acaba de hacer cualquier sudo regular lo hizo, pero no solicitó la contraseña del usuario sin privilegios)?
He leído inicio de sesión y su interior. También he leído ¿Cómo se pretende usar sudo? pero a pesar del título, tratan principalmente de las diferencias entre su y sudo .
Respuesta aceptada:
Si echas un vistazo al ejecutable sudo :
$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
Notarás que lleva los bits de permiso ---s--x--x . Estos se pueden desglosar de la siguiente manera:
-|--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
Entonces, cuando un programa tiene habilitado su bit setuid (también conocido como SUID), significa que cuando alguien ejecute este programa, se ejecutará con las credenciales del usuario propietario del archivo, también conocido como. raíz en este caso.
Ejemplo
Si ejecuto el siguiente comando como usuario saml:
$ whoami
saml
$ sudo su -
[sudo] password for saml:
Notarás que la ejecución de sudo en realidad se está ejecutando como root:
$ ps -eaf|grep sudo
root 20399 2353 0 05:07 pts/13 00:00:00 sudo su -
mecanismo setuido
Si tiene curiosidad sobre cómo funciona SUID, eche un vistazo a man setuid . Aquí hay un extracto de la página del manual que lo explica mejor que yo:
setuid() establece el ID de usuario efectivo del proceso de llamada. Si el
UID efectivo de la persona que llama es raíz, también se establecen el UID real y el
conjunto de ID de usuario guardados. En Linux, setuid() se implementa como
la versión POSIX con la característica _POSIX_SAVED_IDS. Esto permite que un programa
de configuración de ID de usuario (que no sea root) elimine todos sus privilegios de usuario
, realice un trabajo sin privilegios y luego vuelva a activar el ID de usuario original
efectivo en una manera segura.
Si el usuario es root o el programa es set-user-ID-root, se debe tener especial cuidado
. La función setuid() verifica la identificación de usuario efectiva de
la persona que llama y, si es el superusuario, todas las identificaciones de usuario relacionadas con el proceso
se establecen en uid. Después de que esto haya ocurrido, es imposible que el programa
recupere los privilegios de root.
El concepto clave aquí es que los programas tienen un ID de usuario real (UID) y uno efectivo (EUID). Setuid establece el ID de usuario efectivo (EUID) cuando este bit está habilitado.
Relacionado:Ssh:¿cómo funciona tcp-keepalive en ssh?
Entonces, desde la perspectiva del kernel, se sabe que en nuestro ejemplo, saml sigue siendo el propietario original (UID), pero el EUID se ha establecido con quien sea el propietario del ejecutable.
setgid
También debo mencionar que cuando analizamos los permisos en el comando sudo, el segundo grupo de bits era para permisos de grupo. Los bits de grupo también tienen algo similar a setuid llamado set group id (también conocido como setgid, SGID). Esto hace lo mismo que SUID excepto que ejecuta el proceso con las credenciales del grupo en lugar de las credenciales del propietario.
Referencias
- página de wikipedia de setuid
- página man de setuid