Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• es/sudo

Wiki/

---

Root > sudo

---

Sudo es un programa diseñado para facilitar a los administradores del sistema permitir a algunos usuarios ejecutar órdenes como root (u otro usuario). La filosofía básica es permitir a las personas realizar su trabajo otorgándoles los mínimos privilegios posibles. Sudo también se puede usar para registrar quien ejecutó tal orden y cuando.

Razones para usar o no sudo

Por qué la gente usa sudo

Históricamente, los sistemas Unix no usaban sudo. Pero desde el cambio de siglo, sudo (o sus numerosas alternativas para una elevar privilegios de manera más granular) es casi omnipresente en el mundo Linux, tanto en instalaciones privadas de una sola máquina como en grandes centros de datos con cientos de miles de máquinas.

En entornos en la nube y/o contenedores con instancias efímeras, sudo es relativamente poco común, ya que para empezar las instancias en la nube y los contenedores normalmente no tienen cuentas de usuario.

Usar sudo (en lugar de iniciar sesión como root, usar su para root, o ejecutar todo con privilegios totales) facilita varias cuestiones operativas y de seguridad:

Principio de mínimos privilegios

Ejecutas comandos con privilegios elevados solo cuando es necesario. El resto de la sesión se ejecuta sin privilegios, reduciendo el alcance de errores o procesos comprometidos.

Auditabilidad y responsabilidad

sudo registra la ejecución de comandos (normalmente vía syslog o journald). Obtienes:

• quién ejecutó un comando
• cuándo se ejecutó
• qué se ejecutó exactamente

Dejar este tipo de rastro de auditoría es importante en sistemas multiusuario y/o en entornos con requisitos de cumplimiento normativo.

Superficie de ataque reducida

No es necesario habilitar el inicio de sesión directo como root (especialmente por SSH). Los usuarios se autentican con sus propias credenciales, no con una contraseña compartida de root. Esto limita la exposición a ataques de fuerza bruta o reutilización de credenciales dirigidos a root.

No hay que compartir la contraseña de root

Al trabajar en equipos, cada persona inicia sesión y escala privilegios con su propia contraseña. Nadie necesita conocer la contraseña de root, lo que permite restringir el so de la contraseña de root a emergencias. Muchas instalaciones tienen la misma contraseña de root en todas las máquinas con la única copia de la contraseña en texto claro en alguna caja fuerte a la que solo tienen acceso el CTO y sus delegados.

Cuando una persona se va, solo se bloquea su cuenta. Cuando una contraseña se ve comprometida, solo es necesario cambiar la contraseña de esa persona, mientras los demás miembros del equipo pueden seguir trabajando sin verse afectados.

Control de acceso fino

Mediante /etc/sudoers (o archivos en /etc/sudoers.d), puedes:

• permitir solo comandos específicos
• restringir por host, usuario o grupo

• requerir o omitir solicitudes de contraseña (NOPASSWD)

Esto permite delegar sin dar acceso total a root.

Comportamiento más seguro del shell

Trabajar como root de forma interactiva es propenso a fallos:

• errores tipográficos (rm -rf /) se vuelven catastróficos

• los scripts pueden comportarse de forma diferente bajo root
• pegados accidentales pueden ser dañinos

Con sudo, la elevación de privilegios es explícita por comando.

Mejor integración con herramientas modernas

Muchas herramientas del sistema asumen un escalado de privilegios al estilo sudo en lugar de inicio de sesión como root:

• gestores de paquetes (apt, dnf)
• gestión de servicios (systemctl)
• sistemas de gestión de configuración

Tiempo de expiración de sesión y reautenticación

Las credenciales de sudo caducan tras un tiempo configurable. Esto limita el daño si se deja un terminal desatendido.

Separación de responsabilidades

Puedes dar a los operadores capacidades administrativas controladas sin proporcionarles shells root sin restricciones.

Por qué alguna gente no usa sudo

Complejidad añadida sin beneficio

En un sistema de un solo usuario:

• Sin separación de funciones significativa Sin valor de auditoría Configuración extra (sudoers) que mantener

Iniciar sesión directamente como root puede ser más simple y transparente.

Base de código grande

Sudo es un binario suid root relativamente grande y complejo. Introduce la posibilidad de escalado de privilegios no intencionado en caso de errores de software. Existen alternativas con bases de código más modernas y pequeñas que hacen casi el mismo trabajo.

Falsa sensación de seguridad

sudo no hace un sistema seguro por sí mismo:

• Usuarios con reglas amplias ALL=(ALL) ALL son efectivamente root sudoers mal configurado (p. ej. NOPASSWD, reglas demasiado permisivas) invalida las protecciones Los atacantes que obtienen acceso a usuarios suelen escalar vía sudo de todos modos

Exposición y caché de credenciales

• La entrada de contraseña para sudo aumenta la exposición a keyloggers o miradas por encima del hombro El caché de tiempo (timestamp_timeout) permite reutilizar privilegios sin reautenticación sudo -s / sudo -i puede crear shells root de larga duración, derrotando el modelo

Fricción operativa

• Prefijos sudo repetidos en flujos de trabajo y scripts Rompe copiar/pegar de secuencias de comandos a menos que se ajuste Fomenta patrones como sudo sh -c "...", que son más difíciles de razonar y auditar

En la práctica, la gente suele evitarlo iniciando un shell root de todos modos.

Problemas con scripts y automatización

• sudo en scripts introduce problemas de interactividad (solicitudes de contraseña) Requiere manejo extra (NOPASSWD, askpass, ajustes de entorno) En contextos de automatización (CI, contenedores, init), ejecutar como root directamente es más limpio

Inconsistencias de entorno

• sudo restablece o filtra variables de entorno (env_reset) Provoca bugs sutiles (diferencias en PATH, variables ausentes) Requiere preservación explícita (sudo -E), lo que debilita las garantías de seguridad

No está universalmente disponible ni es consistente

• Sistemas mínimos, entornos embebidos y contenedores a menudo omiten sudo Diferentes sistemas tienen políticas sudoers distintas, reduciendo la portabilidad

Fomenta pensamiento de privilegios parciales

En lugar de diseñar límites de privilegios adecuados (capabilities, separación de servicios), la gente:

• concede acceso sudo de forma amplia confía en él como mecanismo de escalado general

Esto puede ser inferior a:

• cuentas de servicio dedicadas capacidades de Linux (setcap) daemons estrictamente acotados

El shell root a veces es más claro

Para tareas administrativas complejas, una sesión root controlada (su - o equivalente)

• evita escalados repetidos reduce el riesgo de mezclar inadvertidamente la propiedad de archivos privilegiados/no privilegiados hace el contexto de ejecución explícito y consistente

Resumen

sudo busca principalmente control, trazabilidad y minimizar riesgos, no solo comodidad. Impone una disciplina en torno a la escalada de privilegios que abarca desde sistemas personales hasta grandes infraestructuras multiusuario.

Advertencias

Ten cuidado al conceder permiso para ejecutar únicamente ciertos comandos. Si los comandos permitidos se pueden retorcer para escalar privilegios (ejemplo obvio: una escapatoria a shell al permitir un editor razonablemente potente), permitir a usuarios ejecutar ese comando les dará efectivamente privilegios de root. Para el caso especial de editar archivos que solo son editables por root, está el comando sudoedit, que hará una copia del archivo que pueda escribir el usuario llamante, ejecutará el editor como ese usuario (anulando la escapatoria a shell como método de escalado) y luego copiará el archivo de vuelta.

Al trabajar en equipo, ten en cuenta que miembros malintencionados pueden usar sus privilegios para construir una puerta trasera que puedan seguir usando después de que se les revoquen los privilegios sudo o incluso su cuenta del sistema. sudo no te libra de la regla de Unix de que «una vez fué root, ya siempre es root».

Cuando un usuario descuidado usa sudo -i o sudo -s para obtener un shell root, no deja ningún rastro útil de auditoría. Si un equipo quiere trazabilidad, debe acordar usar sudo para cada comando individual, nunca abrir un shell root, y cumplir ese acuerdo.

También por eso suele estar desaconsejado «cambiar» a root usando sudo -i (o sudo su), ya que cancela la mayor parte de las ventajas anteriores.

Alternativas

Muchos administradores de Debian no instalan sudo. En su lugar, cuando lo necesitan ejecutan comandos como root (por ejemplo con su - desde una cuenta de usuario normal).

Existen otros programas, como

• run0
• run_as
• sudo-rs
• super

que pueden realizar el mismo trabajo que sudo sin ser tan complejos ni tan extensamente configurables. En la práctica, rara vez se ven en uso estas alternativas.

Instalar sudo

La instalación de sudo ocurre durante la ejecución instalador de Debian, si decides no establecer una contraseña para root. En tal caso, el usuario del sistema que creas durante la instalación pasa a ser miembro del grupo sudo y por tanto puede usar sudo para convertirse en root y en cualquier otro usuario para cualquier comando. Así funcionan también otras distribuciones orientadas al usuario final. El sistema también configurará gksu y aptitude para usar sudo.

Si estableces una contraseña de root durante la instalación, sudo no se instala y el usuario (opcional) que creas no se añade al grupo sudo. Este tipo de instalación se asemeja más a la configuración histórica de Unix. Si quieres sudo en un sistema así, necesitas

• convertirte en root de otra forma,
• instalar el paquete sudo con apt y,

• opcionalmente, añadir a los usuarios que quieras al grupo sudo para que sean equivalentes a root.

$ su --login
Password: 
## (introduce aquí tu contraseña del usuario root que diste durante la instalación de Debian, y dale a Enter)

# apt install sudo

# adduser pepe sudo

(Obviamente substituye "pepe" por el nombre de tu usuario)

Como de costumbre, la pertenencia a grupos solo se aplica al iniciar sesión, así que si acabas de añadirme al grupo sudo, debes cerrar sesión completamente y volver a iniciarla para que la nueva pertenencia tenga efecto. El comando newgrp puede usarse para añadir temporalmente el nuevo grupo en una sola sesión de shell si no quieres cerrar sesión en este momento.

Configurar sudo

El principal archivo de configuración de sudo es /etc/sudoers. Este archivo es de solo lectura, incluso para root: el comando visudo permite a root editarlo, pero es mejor poner la configuración local en archivos dentro de /etc/sudoers.d porque mantiene vigentes los cambios locales aunque el mantenedor de Debian del paquete sudo modifique /etc/sudoers en una nueva versión.

El archivo /etc/sudoers incluído en el paquete de Debian está profusamente comentado y contiene una configuración predeterminada razonablemente segura y algunos ejemplos.

Si desea permitir a ciertos usuarios ejecutar determinados programas, este es un ejemplo rápido (para mas información lea el estupendo manual).

# /etc/sudoers
#
# Este archivo TIENE que editarse como 'root' mediante la orden 'visudo'.
#
# Lea la página man para más detalles sobre cómo redactar un archivo 'sudoers'.
#

Defaults        env_reset

# Especificación del alias del host
User_Alias      MYADMINS = jdoe

# Especificación del alias del usuario

# Especificación del alias de Cmnd
Cmnd_Alias      SHUTDOWN = /sbin/reboot, /sbin/poweroff
Cmnd_Alias      PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude

# Especificación de los privilegios del usuario

# Los usuarios listados arriba (MYADMINS) pueden ejecutar el administrador de paquetes y reiniciar el sistema.
MYADMINS ALL = PKGMGMT, SHUTDOWN

# Los usuarios del grupo wheel pueden ejecutar cualquier orden suplantando a cualquier usuario.
#%wheel ALL= ALL

# Regla por omisión para 'root'.
root    ALL=(ALL) ALL

Exigir la contraseña de root

Si se quiere exigir la contraseña de root para emplear sudo en vez de la del usuario se puede añadir la linea:

Defaults   rootpw

No pedir contraseña

Si se quiere permitir a los miembros del grupo sudo ejecutar órdenes sin que se les pida contraseña, lo cual es en general una mala idea, se puede añadir la linea:

%sudo ALL=(ALL) NOPASSWD: ALL

a un archivo en /etc/sudoers.d. Esto facilitará enormemente obtener acceso de root a quien comprometa esta cuenta, por lo que no se recomienda hacerlo.

NOPASSWD se usa a menudo para permitir que procesos automatizados escalen privilegios automáticamente. Considera las implicaciones, por favor.

Personalizar el tiempo de validez de las credenciales

Por omisión, tras pedir la contraseña sudo recuerda las credenciales durante 15 minutos. Se puede alterar este comportamiento empleando la orden visudo y personalizando el tiempo de validez para un usuario:

Defaults:usuario timestamp_timeout=30

Permitir a usuarios usar sudo

La configuración por omisión de Debian permite a los usuarios del grupo sudo ejecutar cualquier orden mediante el prefijo sudo.

Verificar la pertenencia a sudo

Un usuario puede comprobar si pertenece o no a un grupo sudo usando las órdenes id o groups. Por ej., el usuario pepe debería ver

• $ groups
  pepe sudo

Si sudo no consta en la respuesta es que no es miembro del grupo. Análogamente, la orden id debería producir una respuesta más completa y variable con esta pinta:

• uid=1001(pepe) gid=1001(pepe) groups=1001(pepe),27(sudo)

Problemas y consejos

PATH no establecido

Un error típico al instalar un paquete podría mostrar:

dpkg: warning: 'ldconfig' not found in PATH or not executable.
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable.
dpkg: error: 2 expected programs not found in PATH or not executable.
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.

El archivo /etc/sudoers empaquetado contiene esta linea:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Las versiones anteriores no incluyeron esa linea. Si la máquina tenía un /etc/sudoers modificado localmente (como la mayoría) y luego se actualizó el sistema manteniéndolo, esta nueva línea necesaria faltará. La línea hace que al emplear sudo no se cambie el PATH y con toda probabilidad el PATH no se establezca adecuadamente y le falten los directorios del sistema. La solución es combinar nuestros cambios locales con el nuevo archivo /etc/sudoers del paquete. O mejor llevar tus cambio locales al nuevo /etc/sudoers.d/ con un nombre único como /etc/sudoers.d/sudoers-locales. Ver 639841 para más detalles.

Lo sentimos, el usuario pepe no tiene permitido ejecutar...

Una sesión típica es similar a esta:

• $sudo test
  
  We trust you have received the usual lecture from the local System
  Administrator. It usually boils down to these three things:
  
      #1) Respect the privacy of others.
      #2) Think before you type.
      #3) With great power comes great responsibility.
  
  [sudo] password for jdoe: 
  Sorry, user jdoe is not allowed to execute '/usr/bin/test' as root on localhost.

El mensaje significa lo que dice: el usuario no tiene permitido ejecutar esa orden en esa máquina. Una razón para la confusión sobre esto es que el administrador acaba de añadir al usuario pepe a un grupo privilegiado, pero el usuario continúa usando una sesión vieja, que no tiene la nueva información de los grupos, y por supuesto no tiene los derechos de sudo. Se suele recomendar a la gente que salga y vuelva a entrar al sistema, aunque a veces suele bastar con un reinicio de sesión in situ mediante su - $USER o con cambiar de grupo con newgrp sudo.

El archivo sudoers está protegido contra escritura

Sí, el archivo /etc/sudoers esta protegido contra escritura intencionadamente, ¡incluso para root!

La explicación es que se configuró así para asegurar que los administradores sólo lo editen mediante la orden visudo, que comprueba antes de grabar. Podría parecer que arreglarlo sería tan simple como su -c visudo, pero sudo se suele usar en sitios en los que no se puede escalar a root con su porque no se conoce su contraseña.

Ten en cuenta que muchos editores de texto te dejarán editar el fichero sin quejarse del bit de solo-lectura, así que no obtendrás esta protección adicional automáticamente.

Ver también

• Manpages: sudoers(5), sudo(8), visudo(8), sudoedit(8), sudoreplay(8)