Sudoers: Cambiando de identidad (Parte II de II)

Continuamos con la segunda parte de "Cambiando de identidad". Ayer hablamos sobre el por qué es necesario utilizar sudoer en una organización, y como se puede entender es totalmente necesario tener una delegación de credenciales eficaz y eficiente. Por otro lado, los alias nos permites agrupar acciones, usuarios, entornos bajo el mismo nombre. Hay distintos tipos de alias como por ejemplo Host_Alias, User_Alias y Cmnd_Alias, los cuales son bastante intuitivos. 

Por último, el elemento más importante ya que es el que realiza la concesión de identidad o no, es la ACL. Son las reglas que el administrador definirá para proporcionar la toma de una identidad a un usuario o no. La sintaxis es la siguiente <usuario/%grupo> <host> = [(<runAsUserList>:<runAsGroupList>)] <comando1>,...,<comandoN>.

Lo que se indica en estas líneas es que el root puede ejecutar bajo cualquier identidad cualquier acción, mientras que el usuario pablo puede ejecutar tomando la identidad de root, ya que no se especifica entre paréntesis ni usuarios ni grupos, el comando date y ninguna acción más.

El comando sudo dispone de unos parámetros que son interesantes para aprovechar su potencial. A continuación se presenta un resumen:

• -u. Indicará a sudo que identidad se quiere tomar, si se tiene configurado en el archivo que se puede tener. Si no se especifica el parámetro, se intentará ejecutar la acción con la identidad de root por defecto.
• -k. Este parámetro invalida una sesión anterior de sudo.
• -l. Informa al usuario de sus privilegios como sudoer.

Ejemplo final del archivo

En el siguiente ejemplo final de archivo de sudoers se configura dos usuarios bajo el alias TECNICOS y otro usuario será el administrador y pertenecerá al grupo de administradores. Además, se configura bajo un alias los comandos que los técnicos podrán utilizar. Se puede entender que los técnicos sólo podrán realizar ciertas acciones bajo la identidad del administrador, mientras que éste podrá ejecutar cualquier acción.

Como conclusión añadir que la delegación de privilegios en ciertas acciones a través de sudo permite obtener una capa de seguridad y de control que no dispone a través de la delegación de credenciales genérica. Sudo no deja de ser un software el cual tiene sus versiones y puede tener implementados fallos explotables, por ejemplo últimamente se ha conocido alguno grave que permitía la escalada de privilegios en el sistema, pero manteniendo sudo actualizado la delegación de identidades por acciones es altamente segura.