Usuarios, roles y RBAC en Solaris: por qué root es un rol por defecto y cómo pfexec sustituye a sudo

Qué es

Oracle Solaris implementa la administración privilegiada mediante el control de acceso basado en roles (RBAC): los perfiles de derechos agrupan privilegios y autorizaciones, y se asignan directamente a un usuario o a un rol que el usuario debe asumir de forma explícita. Por defecto en Solaris 11.4, root está configurado como un rol y no como un usuario que pueda iniciar sesión directamente: el administrador entra con su propio usuario nominal y luego asume el rol root para las tareas privilegiadas, en lugar de iniciar sesión como root o de usar su hacia una cuenta anónima compartida.

Por qué importa

Como root es un rol, cada acción privilegiada se puede atribuir al usuario nominal que lo asumió, y ese es el objetivo del diseño: una pista de auditoría mejor que una contraseña de root compartida. sudo no es el mecanismo nativo aquí: las herramientas propias de Solaris (pfexec, los roles, su hacia un rol) son anteriores a él y lo sustituyen. Solaris 11.4 incluye sudo (paquete security/sudo) y en muchas instalaciones está presente, con el usuario inicial del instalador autorizado en /etc/sudoers.d/; pero que esté instalado y lo que el usuario pueda ejecutar con él varía según el host, así que no se puede dar por supuesto.

Cómo aplicarlo

• Para tareas administrativas compartidas, cree un rol en lugar de una cuenta de inicio de sesión normal: roleadd -c "description" -P "<profile>" <rolename>; defina su contraseña con passwd <rolename> y asígnelo con usermod -R +<rolename> <user> (-R <rolename> sin + reemplaza la lista completa de roles del usuario). Un rol no puede iniciar sesión directamente; roles <user> y profiles <user> muestran lo que tiene un usuario.
• Para ejecutar un único comando privilegiado sin abrir una shell de rol persistente, use pfexec <command>. pfexec activa el indicador de proceso de shell de perfiles y ejecuta el comando solo con los derechos de los perfiles asignados al propio usuario que lo invoca, no con los de ningún rol que pueda asumir; los comandos de un perfil de derechos autenticado piden primero la contraseña del usuario.
• Antes de dar por sentado el valor por defecto, compruebe si en un host concreto root es actualmente un rol o un usuario: userattr type root imprime role si es un rol y nada o normal si es un usuario. Solaris permite al administrador cambiarlo en ambos sentidos con usermod -K type=role root (convertirlo en rol) o rolemod -K type=normal root (volver a convertirlo en un usuario con inicio de sesión directo). Antes de convertir root en rol, asigne el rol al menos a un usuario nominal (usermod -R +root <user>) y pruebe su root desde esa cuenta en una segunda sesión; de lo contrario, nadie podrá convertirse en root a través de la red.
• Para scripts desatendidos, asigne un perfil de derechos de alcance muy limitado a la cuenta con la que se ejecuta el script y llame a los comandos privilegiados mediante pfexec; un rol requiere su y su contraseña, lo cual no es adecuado para el uso desatendido.

Trampas

• Suponer que un host con Solaris 11.4 tiene sudo disponible y configurado para usted; compruébelo con command -v sudo y sudo -n -l antes de escribir automatizaciones que lo invoquen.
• Esperar que pfexec use los derechos de un rol: un usuario al que se le ha asignado el rol root pero ningún perfil adecuado no obtiene nada adicional con pfexec; debe asumir el rol con su root (o su <rolename>), que es un paso distinto y auditado.