Usando SUDO

Este artículo se puede leer en el sitio MandrakeSecure.net en inglés, lo traduje porque me pareció muy interesante y el contenido era un tanto poco amigable incluso para los hispanoparlantes habituados a leer documentación en inglés, espero que les sea de utilidad y utilicen con precaución la herramienta sudo.

Usando sudo

Publicado primero en inglés en MandrakeSecure.net

Revisión/Modificación: Nov 5,
2001, Traducción: Feb 27 2004
Autor:Vincent Danen
Traductor:Dardo A. Valdez

Para qué se usa sudo?

Una de mis herramientas de seguridad favoritas es sudo. No es una herramienta para monitorear la seguridad, pero te permite asegurar tu sistema específicamente en aquellos casos en que necesitas dar ciertos privilegios de root a varios usuarios al mismo tiempo.

Veamos un ejemplo simple. Estás corriendo un servidor web y tienes un importante cliente al que le has dado una cuenta de shell en tu sistema. Si tuvieras que ausentarte del sistema durante un tiempo prolongado, probablemente necesitarías poder reinicia Apache si
algo imprevisto le sucediera (problemas). Podrías darle a este cliente, o a otro/s administradores de sitios, acceso por medio de su para permitirles poder reiniciar
el servicio. Ya que Apache usa el puerto 80, necesitas permisos de root para reiniciarlo. Hay tres posibilidades: la primera es darle al cliente la clave de root del sistema, en caso de que necesite reiniciar el servidor. Puedes no darle acceso, y tener el servidor caído hasta que tu puedas reiniciarlo personalmente (una opción factible en realidad, pero no muy buena para el negocio). O puedes usar sudo para darle acceso y autenticación al cliente para reiniciar el servidor web, sin la clave de root y sin darle acceso global a todo tu sistema.

Cuál de estas opciones crees que la mejor?

Obviamente la última. Sudo funciona de ese modo. Con él, puedes tener estricto control sobre tu sistema, permitiendo a ciertos usuarios acceso de root para realizar ciertas tareas sin darles el control de toda la máquina. No necesitas tener el 100% de confianza con sudo, a diferencia de su. Después de todo, si solo quieres que alguien pueda reiniciar el servidor web, para qué darle más posibilidades? Podrán modificar los archivos de configuración de Apache? Añadir nuevos usuarios? Reiniciar otros servidores? Absolutamente no.

Sudo nos ayuda en estos casos; es una herramienta lo suficientemente flexible para satisfacer tus necesidades.

Afortunadamente, viene incluído en prácticamente todas las distribuciones de Linux, desafortunadamente por lo general no se instala por defecto, así que probablemente tengas que instalarla tu mismo. Toma tus cds y hazlo.

Configurando sudo

Sudo es fácil de configurar y tiene un archivo con una sintaxis muy directa. Debes usar el comando visudo para editar el archivo /etc/sudoers. visudo es un wrapper, un intermediario entre sudo y tu editor de textos favorito que hará un control de sintaxis sobre el archivo, una vez que termines de editarlo. Por defecto, si no tienes configurada la variable EDITOR usará el editor vi. Fuera de las opciones del editor en sí, es fácil cambiar que invoca visudo.

Simplemente tipea lo siguiente como root para usar tu editor favorito (en este ejemplo uso Emacs):

[root@linux]# export EDITOR=emacs; visudo

Esto abrirá el archivo /etc/sudoers en emacs. Podés usar cualquier editor que quieras...joe, jed, vim, etc. Ahora que tienes abierto /etc/sudoers es hora de configurar
sudo.

Los comandos de sudo usan una sintaxis básica. Por defecto el archivo /etc/sudoers tendrá una sola instancia:

root	  ALL=(ALL) ALL

Que le indica a sudo que de acceso al usuario root ,con permiso de root, a todos los programas en todo el(los) sistema(s), (precisamente los derechos que tiene el usuario root por naturaleza). La sintaxis es simple:

user	   host = (user) command

La primera columna define el usuario al que se aplica el comando. La sección host define el host en el que tiene validez esta instancia. La sección (user) define el usuario que podrá ejecutar el comando, mientras que la
sección; command define el comando en sí.

También puede definir alias para Hosts, Usuarios, y Comandos usando las palabras clave Host_Alias, User_Alias, y Cmnd_Alias respectivamente.

Veamos unos cuantos ejemplos de diferentes alias que
podrías usar.

Host_Alias	LAN = vader.somehost.com, luke.somehost.com
Host_Alias	SRV = deathstar.somehost.com, dagobah.somehost.com, han.somehost.com
Host_Alias	MAIL = tattoine.somehost.com

Aquí hemos definido tres alias para Hosts. Al primero le dimos el alias de LAN, para identificar a nuestra red interna LAN, y le asignamos dos máquinas: vader.somehost.com,
y luke.somehost.com. El segundo alias es SRV, que identifica a nuestros servidores web y ellos son deathstar.somehost.com, dagobah.somehost.com, y han.somehost.com. El último alias es MAIL, e identifica a nuestro servidor de correo, conteniendo una sola máquina llamada tattoine.somehost.com.

A continuación definimos algunos alias de usuario:

User_Alias	  WEBADMIN = joe, bob
User_Alias	  MAILADMIN = joe, cathy
User_Alias	  BINADMIN = joe, doug

Aquí también tenemos tres alias de usuario. El primer alias tiene el nombre WEBADMIN y es para los administradores web, Joe y Bob. El segundo alias es MAILADMIN, para los administradores del servidor de correo, Joe y Cathy.

Finalmente, definimos el alias BINADMIN para los sysadmins regulares, otra vez Joe y Doug.

Ya hemos definido hosts y usuarios. Ahora tenemos que definir qué comandos podrán ejecutar usando los alias creados:

Cmnd_Alias	   SU = /bin/su
Cmnd_Alias	   BIN = /bin/rpm, /bin/rm, /sbin/linuxconf
Cmnd_Alias	   SWATCH = /usr/bin/swatch, /bin/touch
Cmnd_Alias	   HTTPD = /etc/rc.d/init.d/httpd, /etc/rc.d/init.d/mysql
Cmnd_Alias	   SMTP = /etc/rc.d/init.d/qmail

Aquí también tenemos alias. El primero lo llamamos SU y habilita al usuario para ejecutar el comando /bin/su . El segundo lo llamamos BIN, y permite correr los comandos: /bin/rpm, /bin/rm, y /sbin/linuxconf. El siguiente es SWATCH que permite ejecutar /usr/bin/swatch y /bin/touch. Luego definimos un alias HTTPD el cual permite a sus usuarios ejecutar /etc/rc.d/init.d/httpd y /etc/rc.d/init.d/mysql, para el mantenimiento de los servicios web.

Finalmente definimos SMTP, el cual permite al usuario manejar la ejecución del servidor SMTP qmail.

Ahora tienes que definir como funcionan los alias en conjunto. Aquí es donde le das a cada uno permiso para usar ciertos comandos en determinados hosts. Si hacemos esto del mismo modo que vimos al principio del artículo, esto dará la posibilidad de ejecutar cualquier
programa en cualquier host con permisos de root. Obviamente queremos limitar un poco el acceso en este punto; a continuación vemos un ejemplo basado en los alias
que creamos anteriormente:

WEBADMIN     SRV = HTTPD
MAILADMIN    MAIL = SMTP
BINADMIN     ALL = BIN, SWATCH
joe	     ALL = NOPASSWD: SU
bob	     LAN = BIN

Esto hay explicarlo un poco, pero es fácil de comprender. La primera línea le dice a sudo que permita a aquellos usuarios definidos en el alias WEBADMIN (Joe y Bob), reiniciar Apache y MySQL (comandos definidos en el alias HTTPD), en los sistemas incluídos en el alias SRV (los servidores web). Esto quiere decir que en los sistemas dentro de los alias LAN y el MAIL (el servidor de correo), Joe y Bob no tendrán acceso para hacer lo mismo (reiniciar servicios), sino solo dentro de los tres sistemas definidos en el alias SRV.

La segunda línea le dice a sudo que permita a los usuarios del alias MAILADMIN (Joe y Cathy), reiniciar qmail en tattoine.somehost.com (definido por el alias de host MAIL)

La tercera línea indica a sudo que permita a los usuarios en BINADMIN (Joe y Dough), acceder a los comandos definidos en los alias BIN y SWATCH (que permite manipular la base de datos RPM con permiso de root, borrar cualquier archivo, ejecutar linuxconf para configurar el sistema, ejecutar swatch, y usar el comando touch como root), en todos los sistemas.

La cuarta línea indica a sudo que permita a Joe, nuestro administrador de sistema, usar el alias SU (para ejecutar su), en todas las máquinas sin tener que entrar una clave (más sobre esto a continuación).

La línea final indica a sudo que permita a Bob (quien a veces es requerido para hacer mantenimiento en las máquinas de la LAN), ejecutar los comandos definidos en el alias BIN sobre las máquinas especificadas en el alias LAN.



Bueno, qué quiere decir todo esto? Bien, Joe puede hacer casi cualquier cosa. Teniendo acceso su en todas las máquinas vía sudo, él tiene ese derecho, bueno después de todo él es nuestro administrador de sistema y tiene la clave root de todas formas; el acceso vía sudo es más bien una cuestión de conveniencia para él. Sin embargo, a Dough esto le permite realizar tareas administrativas ejecutando comandos como linuxconf y rpm sobre todos los sistemas, es decir que él es la mano derecha de Joe. Aún así no tiene derechos de acceso para iniciar/detener los servidores web, MySQL y qmail. Cathy sí puede iniciar y detener qmail, pero eso es todo lo que puede hacer. Bob por otro lado, puede iniciar y detener Apache y MySQL en el servidor web, y puede también hacer cierto trabajo administrativo en la LAN (vía rpm y linuxconf), sin embargo no tiene esos ni otros derechos en otras máquinas.

Te habrás dado cuenta de la palabra clave NOPASSWD seguramente. Cada usuario, cuando usa sudo, debe ingresar su propia clave. Por ejemplo, cuando Cathy quiere reiniciar qmail, sudo le pedirá su clave. Ella ingresará su propia clave, no la del root. Esto le indicará a sudo que una persona autorizada está ejecutando el comando. Pero en el caso de Joe, es un poco perezoso y no quiere tipear su clave todo el tiempo, y ya que su compañero de trabajo es el que está escribiendo el archivo sudoers, le pidió que le diera derechos NOPASSWD para ejecutar su. Así que cuando Joe ejecuta su, no tiene que ingresar su clave, pero cuando ejecuta linuxconf (por ejemplo), sí tiene que hacerlo.

Ya te habrás dado cuenta de la flexibilidad que provee sudo. Con un solo archivo, puedes definir derechos de acceso a múltiples máquinas para múltiples usuarios. Lo único que necesitas hacer es tener el mismo archivo en todas las máquinas de la red. Puedes hacer esto usando herramientas como rsync para sincronizar el archivo o usando NIS para hacerlo. De cualquier modo que lo hagas, solo tendrás que mantener un archivo para
todas las máquinas.

Sudo también provee un modo de rastrear a los usuarios que lo utilizan. Añadiendo una línea extra a tu archivo /etc/sudoers, puedes hacer que sudo escriba un archivo de log específico que puedes auditar, por ejemplo:

Defaults      logfile=/var/log/sudo.log, log_year

hará que sudo escriba sus actividades al archivo /var/log/sudo.log. Este archivo se verá luego mas o menos así:

Nov  1 13:44:06 2001 : joe : HOST=vader : TTY=pts/3 ; PWD=/home/joe/mail ;
    USER=root ; COMMAND=/bin/su
Nov  2 13:34:59 2001 : doug : HOST=dagobah : TTY=pts/4 ; PWD=/var/www/html ; 
    USER=root ; COMMAND=/bin/rpm -ivh /mnt/updates/BIG/dis/8.1/RPMS/ucd-snmp-4.2.1-5mdk.i586.rpm 
/mnt/updates/BIG/dis/8.1/RPMS/ucd-snmp-utils-4.2.1-5mdk.i586.rpm

Aquí puedes ver que el primero de noviembre, Joe usó el comando su en el host vader. Asimismo podes ver que el dos del mismo mes, Dough decidió instalar ucd-snmp y ucd-snmp-utils en el host dagoban. Como ves, el archivo log es extremadamente útil para rastrear
quien está haciendo qué, vía sudo.

No necesariamente hace falta convertir usuarios en root al usar sudo. Si, dado el caso, estuvieras ejecutando eggdrop bajo el uid de algún otro usuario (por ejemplo, un tal Stew), tu podrías decirle a sudo que use el id de otro usuario en vez de el del root. Por ejemplo, puedes usar algo como esto:

Cmnd_Alias     IRC = /home/stew/bin/eggdrop, /home/stew/bin/irc/ircd
joe	       deathstar.somehost.com = (stew) IRC

Esto dejará a Joe ejecutar eggdrop e ircd en el directorio home de Stew como si él fuera Stew y no el root, en la máquina con el nombre de host deathstar.

Usando sudo

Ahora que ya has visto como se configura sudo, como lo usas? sudo es muy fácil de usar, como verás. Para determinar qué comandos tienes disponibles para usar vía sudo, podés ejecutar:

[joe@deathstar]$ sudo -l

Password:
User joe may run the following commands on this host:
     (root) /etc/rc.d/init.d/httpd, /etc/rc.d/init.d/mysql
     (root) /bin/rpm, /bin/rm, /sbin/linuxconf
     (root) /usr/bin/swatch, /bin/touch
     (root) NOPASSWD: /bin/su
     (stew) /home/stew/bin/eggdrop, /home/stew/bin/irc/ircd

Este te mostrará exactamente qué comandos puedes ejecutar y cómo qué usuario. Para usar sudo para reiniciar Apache por ejemplo, deberías usar lo siguiente:

[joe@deathstar]$ sudo /etc/rc.d/init.d/httpd restart

Password:

Luego de que Joe le pase su clave, Apache reiniciará. Si él quisiera iniciar eggdrop como Stew, debería hacer algo bastante diferente:

[joe@deathstar]$ sudo -u stew
/home/stew/bin/eggdrop

Password:

Esto ejecutará eggdrop en background con el uid de Stew. Ya que sudo intentará, por defecto, ejecutar como root, debes suministrarle el nombre del usuario si es que no es el root (como en este caso). Observa que pasa si Joe no especifica el nombre de usuario Stew:

[joe@deathstar]$ sudo /home/stew/bin/eggdrop

Sorry, user joe is not allowed to execute '/home/stew/bin/eggdrop' as root 
on deathstar.somehost.com.

Como puedes ver, sudo es muy flexible y muy apto para reemplazar a su. De hecho iría más lejos haciendo disponible su solo a través de sudo. Para que su funcione para usuarios sin permiso de root (quiero decir, para permitirles volverse root u otro/s usuarios incluso), /bin/su debe tener el bit setuid activado, así puede ejecutarse como root. Si remueves el bit setuid de /bin/su, incluso aunque un usuario conozca la clave de root no podrá hacer su a root o a cualquier otro usuario. Quitar el setuid de /bin/su y restringir los logeos de root desde consola y vía SSH es un modo muy efectivo de asegurar la máquina contra accesos no autorizados con permiso de root.

Para poder hacerlo, en ese caso, simplemente asignate a tí mismo acceso sudo para ejecutar su (como lo ejemplificamos con Joe previamente), y luego quita el bit setuid de /bin/su ejecutando como root, lo siguiente:

[root@deathstar]# chmod u-s /bin/su
[root@deathstar]# ls -l /bin/su
-rwxr-xr-x      1 root     root      18172 Sep 14 09:16 /bin/su*

Ahora si intentas ejecutar el comando "su -" como usuario (no como root), incluso si ingresas la clave correcta para el root, no podrás cambiarte a root. Para que alguien pueda usar realmente su, debe existir en sudoers el permiso apropiado y debe ejecutar su a través de sudo de la siguiente manera:

[joe@deathstar]$ sudo su -
[root@deathstar]#

Encuentro este enfoque mucho mejor que restringir el acceso al root. Teniendo su como una aplicación setuid, cualquier usuario en el sistema puede intentar ejecutar su; y si tiene la clave de root o puede adivinarla, se volverá root con todos los derechos que implica. Teniendo su acceso restringido a través de sudo, y con el bit setuid removido, las posibilidades de acceder por la fuerza como root quedan muy limitadas. Piénsalo de esta manera: si alguien puede comprometer tu máquina y obtener acceso de consola como el usuario "apache" o "nobody", con el su setuid, puede intentar logearse como root, y si obtiene la clave nada lo detendrá. Con su acotado sin el bit setuid, incluso si obtiene acceso a una consola como usuario "apache", está limitado solo a los derechos de acceso del usuario "apache". Aunque pueda saber la clave de root, no puede usar su para obtener acceso de root. Es más, ni siquiera puede usar su para volverse Joe (tendría que logearse al sistema desde el principio como Joe).

Para llevar el caso más allá aún, esto significaría que necesitarían acceso a una consola local para logearse como Joe (si es que tienen su clave), o vía SSH (ya que Joe sabe que es mejor eso que telnet). Pero Joe es inteligente. No se metió en el problema de configurar sudo solo para falla ahí. También configuró SSH para rechazar todos los logeos usando la clave y solo permitir logeos basados en autenticación por llaves. Sin la llave privada de Joe, nadie puede logearse en su cuenta vía SSH. Así incluso si tu servidor Apache, Sendmail o DNS permite a alguien obtener acceso de consola a tu sistema con una cuenta sin privilegios (de usuario), el daño que podrían hacer sería mínimo. Sin tener su disponible para usuarios sin privilegios, sin acceso a una consola local y sin poder logearse vía SSH a menos que tengan la llave privada, un atacante debe resolver muchas dificultades para atacar tu servidor para obtener acceso root. Puedes descansar sabiendo que no le has hecho fácil su trabajo tan solo tomando unas pocas y simples medidas de seguridad.

Vamos a tomar un enfoque de autenticación basado en llaves con OpenSSH en el futuro para que puedas redondear apropiadamente la seguridad de tu servidor. Pero por ahora, usa sudo como tu primer línea de defensa en tu sistema.