Guía de Sudo(ers) de Gentoo
1.
Acerca de Sudo
Otorgar permisos
El paquete app-admin/sudo permite al administrador del sistema otorgar
permiso a otros usuarios para ejecutar una o más aplicaciones con las que,
normalmente, no tendrían permisos. A diferencia de usar el bit setuid en
estas aplicaciones, sudo proporciona una buena pizca de control en
quién puede, y cuándo, ejecutar un determinado comando.
Con sudo puede hacer una completa lista de quién puede ejecutar
una determinada aplicación. Si estableciera el bit setuid, cualquier usuario
sería capaz de ejecutar la aplicación (o cualquier usuario de un grupo en
concreto, dependiendo de los permisos empleados). Puede (e incluso debería)
exigir al usuario que proporcione una contraseña cuando éste quiera ejecutar la
aplicación, y hasta puede afinar mejor los permisos basados en la localización
del usuario: conectado desde el propio sistema o a través de SSH, desde un
sitio remoto.
Actividad del registro
Una de las ventajas adicionales de sudo es que registra cualquier
intento (satisfactorio o no) de ejecución. Esto es de gran utilidad si le
quiere seguir la pista al que hizo ese error fatal que le llevó diez horas
arreglar :)
Configurar Sudo
La configuración de sudo la gestiona el fichero
/etc/sudoers. Éste nunca debe ser editado a través de
nano /etc/sudoers o vim /etc/sudoers o cualquier otro
editor preferido. Cuando desee modificar este fichero, tendrá que utilizar
visudo.
Esta herramienta asegura que no hayan 2 administradores del sistema editando el
fichero al mismo tiempo, conserva sus permisos y realiza comprobaciones de
sintaxis para cerciorarse de que no se cometan errores fatales en el fichero.
Acerca de esta guía
Esta guía pretende ser una introducción rápida. El paquete sudo es mucho
más potente que lo que aquí se describe. Tiene características especiales para
la edición de ficheros como un usuario distinto (sudoedit), ejecutarse
desde un script (por lo que puede estar en segundo plano, leer la contraseña
desde la entrada estándar en vez del teclado, ...), etc.
Por favor, lea las páginas de sudo y sudoers del manual para
mayor información.
2.
La sintaxis de Sudoers
Sintaxis básica
La parte más difícil de sudo es la sintaxis de
/etc/sudoers. La sintaxis básica es la siguiente:
Listado de Código 2.1: Sintaxis básica de /etc/sudoers |
user host = commands
|
Esta sintaxis le dice a sudo que el usuario, identificado como
user y conectado a través del sistema host, puede ejecutar
cualquiera de los comandos listados en commands como usuario root. Un
ejemplo más real podría ser más clarificador: permitir al usuario swift
ejecutar emerge si está conectado desde el sistema (y no a través de
SSH):
Listado de Código 2.2: Ejemplo real de /etc/sudoers |
swift localhost = /usr/bin/emerge
|
De todos modos, una gran advertencia: no deje que un usuario
ejecute alguna aplicación que pueda permitir incrementar los permisos. Por
ejemplo, permitir que los usuarios ejecuten emerge como root puede en
efecto otorgarles acceso total al sistema, puesto que emerge se puede
modificar para cambiar el comportamiento del sistema de ficheros en beneficio
del usuario. Si no confía en sus usuarios que pueden emplear sudo, no
les conceda ningún derecho.
El nombre de usuario también se puede sustituir por un nombre de grupo - en
este caso, debería anteponer el signo % al nombre de grupo. Por ejemplo,
para permitir que cualquiera del grupo wheel ejecute emerge:
Listado de Código 2.3: Permitir la ejecución de emerge a los miembros del grupo wheel |
%wheel localhost = /usr/bin/emerge
|
Puede ampliar la línea para permitir varios comandos (en lugar de escribir una
por cada comando). Por ejemplo, para permitir al mismo usuario ejecutar como
root no solamente emerge sino también ebuild y
emerge-webrsync:
Listado de Código 2.4: Múltiples comandos |
swift localhost = /usr/bin/emerge, /usr/bin/ebuild, /usr/sbin/emerge-webrsync
|
Puede incluso especificar un comando preciso y no sólo la herramienta en sí
misma. Esto es útil para restringir el uso de cierta herramienta con un grupo
específico de argumentos. La herramienta sudo también permite el uso de
metacaracteres propios de la shell en nombres de ruta, además de como
argumentos dentro del fichero sudoers. Fíjese que no son expresiones
regulares.
Pongamos esto a prueba:
Listado de Código 2.5: Intentar actualizar el sistema mediante sudo |
$ sudo emerge -uDN world
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.
Password:
|
La contraseña pedida por sudo es la del propio usuario. Esto es para
asegurarse de que ninguna terminal abierta a otros por error sea utilizada con
fines dañinos.
Debería saber que sudo no cambia la variable ${PATH}: cualquier
comando situado después de sudo es tratado desde su entorno. Si
desea que el usuario ejecute una herramienta ubicada en, por ejemplo,
/sbin éste debería proporcionar a sudo la ruta completa,
algo como:
Listado de Código 2.6: Utilizar la ruta completa de una herramienta |
$ sudo /usr/sbin/emerge-webrsync
|
Utilizar alias
En entornos más grandes que tengan que dar acceso a todos los usuarios una y
otra vez (o hosts, o comandos) puede ser una impresionante tarea. Para
facilitar la administración de /etc/sudoers, puede definir
alias (accesos directos). El formato para declarar alias es muy
fácil:
Listado de Código 2.7: Declarar alias en /etc/sudoers |
Host_Alias hostalias = hostname1, hostname2, ...
User_Alias useralias = user1, user2, ...
Cmnd_Alias cmndalias = command1, command2, ...
|
Un alias que siempre funciona, en cualquier posición, es ALL (para
distinguir correctamente entre lo que son y no son alias, se recomienda
utilizar mayúsculas para los alias). Como indudablemente pueda haber pensado,
el alias ALL sirve para todas las opciones posibles.
Un ejemplo de uso del alias ALL para permitir a cualquier usuario
ejecutar el comando shutdown si está localmente en el sistema:
Listado de Código 2.8: Permitir a cualquiera ejecutar shutdown |
ALL localhost = /sbin/shutdown
|
Otro ejemplo es permitir al usuario swift ejecutar el comando
emerge como root, ignorando desde dónde haya iniciado sesión:
Listado de Código 2.9: Permitir a un usuario ejecutar una aplicación ignorando su localización |
swift ALL = /usr/bin/emerge
|
Más interesante es definir un conjunto de usuarios que puedan ejecutar software
administrativo (como por ejemplo emerge y ebuild) en el sistema y
un grupo de administradores que puedan cambiar la contraseña de cualquier
usuario, excepto de la de root:
Listado de Código 2.10: Utilizar alias para usuarios y comandos |
User_Alias SOFTWAREMAINTAINERS = swift, john, danny
User_Alias PASSWORDMAINTAINERS = swift, sysop
Cmnd_Alias SOFTWARECOMMANDS = /usr/bin/emerge, /usr/bin/ebuild
Cmnd_Alias PASSWORDCOMMANDS = /usr/bin/passwd [a-zA-Z0-9_-]*, !/usr/bin/passwd root
SOFTWAREMAINTAINERS localhost = SOFTWARECOMMANDS
PASSWORDMAINTAINERS localhost = PASSWORDCOMMANDS
|
Ejecución como usuario no root
También es posible tener un usuario para ejecutar una aplicación como otro
usuario distinto de root. Esto puede ser muy interesante si ejecuta
aplicaciones como un usuario diferente (por ejemplo, apache para el
servidor web) y desea permitir a ciertos usuarios realizar labores
administrativas (como matar procesos zombi) como ese usuario.
En /etc/sudoers añada el/los usuario/s entre
( y ) antes del listado de comandos:
Listado de Código 2.11: Sintaxis de ejecución como usuario no root |
users hosts = (run-as) commands
|
Por ejemplo, para permitir a swift ejecutar la herramienta kill
como usuario apache o gorg:
Listado de Código 2.12: Ejemplo de ejecución como usuario no root |
Cmnd_Alias KILL = /bin/kill, /usr/bin/pkill
swift ALL = (apache, gorg) KILL
|
Con esta configuración, el usuario puede ejecutar sudo -u para
seleccionar el usuario con el que desea ejecutar la aplicación:
Listado de Código 2.13: Ejecutar pkill como usuario de apache |
$ sudo -u apache pkill apache
|
Mediante la directiva Runas_Alias, puede establecer un alias para el
usuario con el que se va a ejecutar una aplicación. Su uso es idéntico al de
otras directivas _Alias vistas anteriormente.
Contraseñas y opciones por defecto
Por defecto, sudo le pide al usuario que se identifique con su propia
contraseña. Una vez que la introduce, sudo la recuerda
durante cinco minutos dejando al usuario centrarse en sus tareas sin tener que
estar reescribiendo su contraseña cada vez.
Esta conducta, por supuesto, se puede cambiar: puede establecer la
directiva Defaults: en /etc/sudoers para cambiar el
comportamiento por defecto para un usuario.
Por ejemplo, para cambiar los 5 minutos preestablecidos a 0 (no recordarla
nunca):
Listado de Código 2.14: Cambiar el tiempo de expiración |
Defaults:swift timestamp_timeout=0
|
La opción -1 haría recordar la contraseña permanentemente (hasta
reiniciar el sistema).
Una configuración diferente sería exigir la contraseña del usuario con el que
se ejecutaría el comando y no la propia contraseña personal de los usuarios.
Esto se consigue utilizando runaspw. En el ejemplo siguiente, también
fijaremos el número de intentos (cuántas veces puede el usuario reintroducir
una contraseña antes de que sudo falle) a 2, en el lugar de los 3
predeterminados:
Listado de Código 2.15: Exigir la contraseña de root en vez de la del propio usuario |
Defaults:john runaspw, passwd_tries=2
|
Otra característica interesante es mantener definida la variable DISPLAY
de modo que pueda ejecutar herramientas gráficas:
Listado de Código 2.16: Mantener viva la variable DISPLAY |
Defaults:john env_keep=DISPLAY
|
Puede cambiar docenas de opciones predeterminadas mediante la directiva
Defaults:. Dele caña a la página del manual de sudo y busque
por Defaults.
Si, no obstante, desea permitirle a un usuario ejecutar un cierto grupo de
comandos sin proporcionar ningún tipo de contraseña, necesita entonces empezar
los comandos con NOPASSWD:, así:
Listado de Código 2.17: Permitir que emerge sea ejecutado como root sin pedir contraseña |
swift localhost = NOPASSWD: /usr/bin/emerge
|
3.
Utilizar Sudo
Listar privilegios
Ejecute sudo -l para informarse de cuáles son sus capacidades:
Listado de Código 3.1: Listar capacidades |
$ sudo -l
User swift may run the following commands on this host:
(root) /usr/libexec/xfsm-shutdown-helper
(root) /usr/bin/emerge
(root) /usr/bin/passwd [a-zA-Z]*
(root) !/usr/bin/passwd root
(apache) /usr/bin/pkill
(apache) /bin/kill
|
Si tiene cualquier comando en /etc/sudoers que no le pida que
introduzca una contraseña, tampoco se le pedirá una contraseña para listar las
entradas. De no ser así, podría ser preguntado por su contraseña si ésta no es
recordada.
Prolongar el tiempo de expiración de la contraseña
Por defecto, si un usuario ha introducido su contraseña para autenticarse ante
sudo, ésta es recordada durante cinco minutos. Si el usuario quiere
prolongar este periodo, puede ejecutar sudo -v para reiniciar la
marca de tiempo de modo que coja otros cinco minutos antes de que sudo
pregunte de nuevo por la contraseña.
Listado de Código 3.2: Prolongar el tiempo de expiración de la contraseña |
$ sudo -v
|
Lo contrario es matar la marca de tiempo usando sudo -k.
El contenido de este documento está registrado bajo los términos de
la licencia
Creative Commons - Reconocimiento / Compartir Igual
|