Porque sudo permite controles mucho más detallados que "iniciar sesión como root y luego hacer lo que quieras". Por ejemplo, puede configurar sudo para que algunos usuarios solo puedan ejecutar ciertos comandos (como scripts de envoltura o archivos binarios "aceptables"). Le preocupa que un caballo de Troya comprometa la computadora de un solo usuario, pero sudo se creó para permitir el registro y el control de acceso en un servidor administrado por varias personas.
Por supuesto, en un sistema de un solo usuario, los archivos importantes son los archivos del usuario, y una vez que obtiene acceso a la cuenta del usuario, ya tiene acceso a esos archivos , por lo que obtener la contraseña ya no es tan importante. Incluso si la contraseña es su objetivo (digamos, está atacando a alguien que reutiliza contraseñas), hay muchas maneras de obtenerla sin involucrar a sudo; por ejemplo, recientemente me encontré con 2 programas instalados de forma predeterminada que registrarán contraseñas o errores de contraseña en texto sin formato.
Y finalmente, es recomendable no ejecutar como root siempre que sea posible porque las consecuencias de escribir mal un comando (rm_-rf_._/ es un ejemplo obvio) no son tan graves. Requerir el paso adicional de escribir sudo al comienzo de un comando en lugar de "olvidar que está conectado como root y hacer algo destructivo" puede evitar algunos errores simples pero graves.
Hay usos de conveniencia válidos para sudo, pero debido a que ya se explican adecuadamente en otras publicaciones, no los explicaré mucho aquí. Sin embargo, te indicaré sudoers(5) , que es el archivo de configuración de sudo. Muestra parte de la amplia configuración posible con sudo. Explicaré cuándo y por qué no debe usar sudo para pasar de su usuario normal a root por razones puramente de seguridad, dejando de lado la conveniencia.
Respuesta corta: No hay forma de usar sudo de forma segura si su usuario habitual puede verse comprometido. Úselo solo por conveniencia, no por seguridad. Lo mismo se aplica a su y todos los demás programas que pueden usarse para elevar su usuario habitual a uno más privilegiado.
Respuesta larga: No es cierto que usar la ruta completa para sudo lo protegerá de un entorno malicioso. Ese es un malentendido común. Una función bash puede incluso secuestrar nombres que contengan un / al principio. Intenta ejecutar lo siguiente:
$ echo $SHELL
/bin/bash
$ function /usr/bin/sudo { echo "Trust me, now put in your password:"; }
$ /usr/bin/sudo id
Trust me, now put in your password:
debes solo use la opción 1, también conocida como iniciar sesión con agetty o iniciar sesión en un tty diferente (tenga en cuenta que en algunas distribuciones, tty1 es donde se ejecuta Xorg, como Fedora. Sin embargo, en la mayoría de las distribuciones, tty1 es un tty de repuesto y Xorg se ejecuta en tty7) . Sin embargo , debe tener en cuenta que el malware puede secuestrar ctrl +alt +f1 y presentarte una pantalla falsa, por lo que debes usar la combinación de Clave de Atención Segura (SAK, que es alt +sysrq +k en sistemas Linux), que elimina todos los procesos en ese tty. Esto elimina cualquier pantalla de inicio de sesión falsa y lo lleva solo a la real. Si no hay pantallas de inicio de sesión falsas que intenten robar su contraseña de root (que es de esperar que sea el caso), simplemente hace que agetty se reinicie, lo que debería aparecer como nada más que el indicador de inicio de sesión parpadeando. En algunos sistemas, muchas funciones de SysRq están deshabilitadas, incluido SAK. Puede habilitarlos todos temporalmente escribiendo el número entero 1 a /proc/sys/kernel/sysrq . El valor de /proc/sys/kernel/sysrq es un mapa de bits, así que mire lo que es actualmente y calcule en qué necesita convertirlo para agregar compatibilidad con SAK antes de hacerlo permanente en /etc/sysctl.conf . Establecerlo en 1 para siempre puede ser una mala idea (no desea que cualquiera pueda alt +sysrq +e para matar xscreensaver, ¿verdad?).
La idea de que puede proteger a su usuario habitual y usar sudo o su de forma segura es una idea muy peligrosa. Incluso si fuera posible, existen innumerables formas de secuestrar su sesión en ejecución, como LD_PRELOAD , que es una variable ambiental que apunta a un objeto compartido (biblioteca) que el programa cargará a la fuerza para cambiar su comportamiento. Si bien no funciona en programas setuid como su y sudo, sí funciona en bash y todos los demás shells, que ejecutan su y sudo, y son los que ven todas las pulsaciones de teclas. LD_PRELOAD no es la única variable que puede secuestrar programas que se ejecutan como su usuario. LD_LIBRARY_PATH puede decirle a un programa que use bibliotecas maliciosas en lugar de las bibliotecas de su sistema. Hay muchas más variables ambientales que se pueden usar para cambiar el comportamiento de los programas en ejecución de varias maneras. Básicamente, si sus variables ambientales pueden verse comprometidas, su usuario y todas las pulsaciones de teclas ingresadas como ese usuario pueden verse comprometidas.
Si eso no fuera suficiente, en la mayoría de las distribuciones, su usuario puede usar ptrace() con el GETREGS o PEEKTEXT/PEEKDATA opciones para ver toda la memoria de los procesos que se ejecutan como el mismo usuario (como el proceso bash que ejecuta su o sudo por usted). Si está utilizando una distribución que deshabilita eso (por ejemplo, mediante el uso de Yama LSM), el proceso aún puede leer y escribir en la memoria de su proceso bash usando process_vm_readv() y process_vm_writev() respectivamente. En algunos núcleos, también puede escribir directamente en la memoria a través de /proc/pid/mem , siempre que el proceso que escribe en él sea el mismo usuario. En el kernel de Linux, existen innumerables controles de seguridad para asegurarse de que los procesos no puedan interferir entre sí. Sin embargo, todos involucran inter -protección del usuario, no intra -protección del usuario. El kernel de Linux asume que el usuario A confía en todo lo que se hace como usuario A, por lo que si usted hace su a root como usuario A, entonces root debe ser tan confiable como ese usuario.
Antes de pasar a Xorg, permítanme comenzar diciendo que Xorg no brinda protección contra los registradores de pulsaciones de teclas. Esto significa que, si usa sudo o su en un tty con Xorg ejecutándose, todos los procesos que se ejecutan como ese mismo usuario podrán olfatear (e inyectar) pulsaciones de teclas. Esto se debe a que el modelo de seguridad del protocolo X11 asume que todo lo que tenga acceso a la cookie X11 es confiable, y esa cookie es accesible para todo lo que se ejecuta bajo su usuario. Es una limitación fundamental del protocolo X11, arraigada tan profundamente como lo está el concepto de UID en Linux. No hay ninguna configuración o función para deshabilitar esto. Esto significa que todo lo que escriba en una sesión de Xorg, incluido lo que escriba en su o sudo (o interfaces como gksu, gksudo, kdesu, kdesudo, pinentry, etc.) puede ser rastreado por cualquier cosa que se ejecute como el mismo usuario, por lo que su navegador, sus juegos , su reproductor de video y, por supuesto, todo lo que se bifurca con su .bashrc. Puede probar esto usted mismo ejecutando lo siguiente en una terminal y luego moviéndose a otra terminal y ejecutando un comando con sudo.
$ xinput list
Virtual core pointer id=2 [master pointer (3)]
↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ USB Camera id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Asus WMI hotkeys id=11 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
$ xinput test 12 # replace 12 with the id number of your keyboard
key press 45
key press 44
key release 40
key press 41
key release 45
key release 44
key release 41
key press 31
^C
Tenga en cuenta que si esta prueba específica no funciona para usted, significa que no tiene el XTEST extensión activa. Incluso sin que esté activo, aún es posible grabar eventos de teclado usando XQueryKeymap() . La lección que debe aprender es que efectivamente no hay manera para ingresar de forma segura su contraseña usando su o sudo a través de un usuario comprometido. Absolutamente debe cambiar a un nuevo tty y usar SAK, luego inicie sesión directamente como root.
Además de lo mencionado por otros usuarios, sudo también mantiene la identidad original del usuario que ejecuta el comando. Lo que significa que puede rastrear qué ID de usuario realizó el comando. Si está utilizando la raíz en un entorno multiusuario, no podrá rastrear la ejecución de un comando para un solo usuario ya que el uid será 0.