Antes de sudo, los sysadmins compartían la contraseña de root... Algo realmente peligroso. Y que hoy en día ningún veterano de linux se plantearía, La solución nació, en SUNY Buffalo, en la universidad local de dos mentes brillantes.
Bob Coggeshall y Cliff Spencer, como decía antes, En los inicios de Unix, compartir la contraseña de root era una práctica común... Hasta que estos dos administradores se dieron cuenta del riesgo.
Pero antes hablemos de que es sudo.
su (switch user): Para cambiar a superusuario.
do (hacer): Acción que se ejecutaría como otro usuario.
¡SuperUser DO! → sudo.
Sudo significa SuperUser DO, y es una herramienta del sistema que permite a los usuarios especificados en el archivo de configuración /etc/sudoers, la ejecución de comandos con los privilegios de otro usuario (incluido root), es decir un "usuario privilegiado".
En /etc/sudoers, se especifica quién está autorizado a hacer qué, con los privilegios de quién. De hecho, la finalidad de sudo es reemplazar a su. No voy a profundizar mucho en esto pero les diré que si quieren conocer acerca de este comando pueden consultar los enlaces en este artículo, donde incluyo algunos videos de los canales de Last Dragon y la Chica de Sistemas, personas con amplios conocimientos sobre el tema y además con excelentes canales de youtube.
Por defecto, sudo requiere que los usuarios se identifiquen con su propia clave de acceso. Una vez identificado correctamente, el usuario podrá utilizar nuevamente sudo sin necesidad de una nueva identificación durante un periodo temporal determinado en /etc/sudoers, (por defecto: cinco minutos).
Prácticamente sudo permitió en parte una de las bases de la seguridad en Linux, un sistema multi usuarios, la sintaxis básica de la orden sudo es: $ sudo opción comando.
La secuencia de la ejecución de un comando vía sudo (sin opciones), sería la siguiente: $ sudo pacman –Syu
Por poner un ejemplo, o también $ sudo apt update en Debian o derivadas.
De la mano de BSD
Pero volvamos a los inicios de sudo, Su historia se remonta a 1980 en los albores de Unix, cuando fue desarrollado por Bob Coggeshall y Cliff Spencer en el Departamento de Ciencias de la Computación de la SUNY Buffalo (Nueva York), usaban computadoras PDP-11/70 corriendo BSD 4.1.1. Como los administradores de sistemas compartían la contraseña de root para tareas de mantenimiento. Esto generaba dos graves riesgos:
· Falta de auditoría: Imposible rastrear quién ejecutaba comandos críticos.
· Seguridad comprometida: Si un administrador dejaba el equipo, debían cambiar la contraseña de root para todos.
Se dice que todo comenzó En una tarde de 1980, durante una sesión de mantenimiento del servidor compartido: Cliff Spencer accidentalmente ejecutó rm -rf /tmp/* como root... pero se equivocó de directorio y borró datos críticos. Bob Coggeshall comentó: "Necesitamos algo que nos permita dar permisos temporales sin regalar la llave maestra".
Básicamente la pregunta que se formularon fue: ¿cómo permitir a los usuarios ejecutar tareas críticas sin compartir la contraseña de root? La respuesta que ahora todos conocemos fue sudo, cuatro letras que prácticamente otorgan poder casi absoluto sobre un sistema operativo, aquellos administradores de BSD Unix, encontraron una solución brillante, ejecutar comandos privilegiados, sin comprometer la seguridad del sistema.
En otras palabras, con sudo, un usuario autorizado puede ejecutar comandos del sistema como si fuera root, sin iniciar sesión como root.
Cuando crearon una base rudimentaria de sudo hicieron una prueba la anécdota que puede ser real o no dice que como en una prueba de fuego:
Coggeshall le dio acceso sudo a Spencer solo para comandos de backup.
Spencer intentó ejecutar sudo rm /old_logs/*... pero recibió:
cliff is not allowed to run rm on this host.
Command logged.
Se dice que Cliff conocido por su habilidad y rapidez, se sentó y escribió la primera versión de sudo en un solo fin de semana. La leyenda dice que fue increíblemente conciso, escribiendo alrededor de 200 líneas de código en lenguaje C, la innovación clave en gran medida fue la creación del archivo de configuración /etc/sudoers, donde se podrían escribir las reglas para los usuarios que usarían sudo. Verdad o mito, sudo llegó para quedarse.
El legado de Ubuntu.
Ahora hablemos de dónde y cómo vino la popularidad de sudo en Linux... Hay un viejo adagio que reza que todo tiempo pasado siempre fue mejor, bueno, en 2004, Ubuntu fue lanzado con una nueva filosofía: “seguridad y simplicidad”. Ubuntu tuvo éxito casi espontáneo, una de las claves fue su agresiva y valiente campaña de marketing, crear isos y regalarlas en cd a todo el que lo pidiera, así como en escuelas y universidades, pero otro motivo de su éxito fue, eliminar el acceso root por defecto y usar sudo para todo.
El señor Mark Shuttleworth y su equipo decidieron que el usuario final no necesitaba saber nada de contraseñas de root, y esto además ayudaría a mantener la seguridad del sistema.
Esto redujo errores, facilitó la administración y creó un rastro auditable de todo lo que se hacía con privilegios elevados, dicho rastro lo podemos encontrar en el archivo de logs: var/log/auth.log. Pero acá les dejo una tabla con varias distribuciones poplares porque dependiendo de la distribución el archivo donde se guaran los logs, puede cambiar.
Sudo puede registrar los intentos de acceso, exitosos y fallidos, así como los errores, en syslog, en este archivo /var/log/auth.log. Todo queda registrado, nada pasa desapercibido.
Ubuntu no creo sudo, de hecho este ya tenía más de tres décadas de existir, pero lo convirtió en un estándar. Pronto otras distribuciones lo adoptaron como modelo.
Ojalá actualmente hubiera más decisiones así de buenas, pero la contribución ahí está no puede negarse y fue enorme, el resto es historia.
El cambio de paradigma fue tal, que hoy el 90% de usuarios de Linux usan sudo como norma. Lo que empezó como una herramienta para evitar compartir contraseñas, hoy es un pilar de la administración moderna de sistemas Linux. Sin embargo, usar sudo con cuidado es parte del arte de administrar sistemas. Con un gran poder, viene una gran responsabilidad.
No uses sudo su.
Seguramente si eres usuario de Linux has oído en más de una ocasión que no es correcto usar sudo su. Pero te has preguntado porque? o te lo han dicho y la respuesta no fue convincente?
Bueno analicemos un poco porque no es correcto usar sudo su, en primer lugar, va contra la misma naturaleza de sudo, la idea de sudo es reemplazar su pero de una forma más controlada, dicho de otra manera, ejecutar comandos como root, pero sin riesgo de dañar el sistema con un control sobre los riesgos, al hacer sudo su estamos rompiendo el principio de mínimo privilegio que nos regala sudo.
• sudo fue diseñado para ejecutar comandos específicos con privilegios.
• sudo su te da una sesión completa de root (¡poder ilimitado!), aumentando el riesgo de: Errores catastróficos (rm -rf /), Vulnerabilidades si la terminal es comprometida, de hecho si es posible romper el sistema a pesar de sudo si tienes conocimientos avanzados y conoces las opciones correctas.
Otro problema es que eliminamos el control y la auditoría que teníamos solo con sudo:
• sudo su anula las restricciones del archivo sudoers, al ejecutar sudo su prácticamente eres root, es un sinsentido.
• Con sudo. Se registra quién, cuándo y qué comando se ejecutó en /var/log/auth.log o su equivalente para cada distribución.
• Con sudo su. Solo se registra el inicio de sesión (sudo su), Los comandos posteriores son invisibles en los logs.
Si quieres comprenderlo mejor te dejo un video del amigo Last Dragon sobre el tema.
https://www.youtube.com/watch?v=Edk7tDNv7Vo
Edita sudoers con visudo.
Usar visudo para editar el archivo /etc/sudoers no es solo una recomendación, es una obligación de seguridad en Linux.
Cómo surgió visudo.
Los creadores de sudo (Coggeshall y Spencer, SUNY Buffalo, 1980) incluyeron visudo desde las primeras versiones. Sabían que un archivo de configuración tan crítico debía protegerse contra errores humanos y conflictos.
Porque usar visudo punto por punto:
1. Previene errores de sintaxis que bloquean el acceso sudo
El archivo sudoers tiene una sintaxis estricta. Un error mínimo (como una coma faltante, espacio extra o línea mal formada) puede invalidar todo el archivo, en consecuencia todos los usuarios (incluido root temporalmente) perderían acceso a sudo. Tendrías que arreglarlo desde un modo de rescate. Con visudo se verifica la sintaxis antes de guardar. Si hay errores, muestra un mensaje claro y pregunta si quieres corregirlo o descartar los cambios.
2. Bloqueo de archivo para evitar ediciones simultáneas
Si dos administradores editan /etc/sudoers al mismo tiempo (con nano o vim), los cambios de uno sobrescribirán los del otro. Visudo usa un mecanismo de bloqueo (/etc/sudoers.tmp.lock). Y si el archivo ya está siendo editado, muestra algo como: /etc/sudoers busy, try again later
3. Cumple con permisos y ownership seguros
Si editas manualmente con sudo nano /etc/sudoers, Podrías cambiar accidentalmente los permisos (ej: chmod 777). O modificar el ownership (ej: chown usuario:usuario). sudo rechazará ejecutarse si los permisos no son 0440 o el owner no es root.
En cambio con visudo se abre una copia temporal con permisos y ownership correctos, y al guardar, la copia reemplaza al original manteniendo los atributos seguros.
4. Respeta el editor de texto configurado
Flexibilidad: visudo usa el editor definido en $EDITOR o $SUDO_EDITOR. Si prefieres nano, o vim puedes ejecutar:
sudo EDITOR=nano visudo # Usa nano
sudo EDITOR=vim visudo # Usa vim
Y si no se define usa el editor por defecto. Normalmente vi
5. ¿Qué pasa si lo editas manualmente?
• Si cometes un error de sintaxis, pierdes acceso a sudo (y quizá al servidor).
• Si otro administrador edita al mismo tiempo, se perderán cambios.
• Si alteras permisos, sudo dejará de funcionar hasta que los repares en modo rescate.
En Conclusión, usar visudo es como tener un escudo al editar /etc/sudoers. Que te protege de ti mismo, de errores técnicos y de otros administradores. Comando seguro siempre: sudo visudo
Te dejo por acá un corto video de La Chica de sistemas que ilustra de una manera muy didáctica y entretenida y con conocimiento de sobra, todo esto que he tratado de explicar. https://www.youtube.com/watch?v=BTv2oE0q_bM
Para finalizar esta es mi pequeña reflexión, sin Bob y Cliff, sudo no existiría, Sin BSD no hubiera sido posible. Sin Ubuntu, sería un comando oscuro y poco conocido.
Hoy es el gran ecualizador: da poder a los usuarios... sin darles la llave del reino.
Así que la próxima vez que uses sudo, recuerda: detrás hay más de 40 años de historia... y una filosofía: el poder debe contenerse y auditarse. Gracias por leer y larga vida al software libre.
Excelente articulo Mí Querido Carlos...
ResponderBorrarGracias estimado Nolberto.
BorrarGracias amigo Nolberto.
ResponderBorrar