Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión, toca hablar de <roles>, ya que hemos avanzado en nuestros conceptos del modelo de seguridad de Solaris.
He decidido dividir esta parte de manejo de roles en varias entregas, y utilizar el ejemplo de Cómo Instalar PostgreSQL en OpenIndiana para reflejar las ventajas de utilizar roles y autorizaciones. En esta primera parte, nos acercaremos al concepto de roles y cómo se crean.
Qué es un rol
Un rol es gan parte similar a un usuario con la diferencia que no es posible iniciar una sessión con él. Me explico, imaginemos que tenemos un rol llamado postgres, si quieramos iniciar sessión con él, el sistema nos mostraría el siguiente error:
console login: postgresAnalizando el error, nos informa que sólo una vez en el sistema, podemos asumir el rol si estamos autorizados. Es aquí donde encontramos las diferencias.
Password: ********
Roles can oly be assume by authorized users
Login incorrect
Relamente Necesito Roles
Buena pregunta, yo tardé unos meses en ver que sí, pero hasta entonces no lo tenía muy claro. Cuando llevaba unos meses adminstrando Solaris -allá por el Solaris 8- descubrí una funcionalidad que venía de Trusted Solaris, los Roles. Al principio, no veía por qué tenía que ir "asumiendo" un Rol u otro en función de qué tarea quisiera hacer, así que al final decidí volver a mi tradicional "su -" y realizarlo con root.
Un día, cuando ya no era yo sólo el que administraba los Solaris, me encontré con "un toquecito en la espalda diciéndome: es que ... no sé ... pero .... el servidor de correo no funciona ... y yo no he tocado nada"
Aquí empezaron mis problemas ... ya que root tiene el control de todo, pero .. quién controla a root? Y más importante: Qué "root" ha sido?
Si analizamos los registros de auditoria, vemos que el comando lo ha ejecutado "root", pero si tenemos varios SysAdmin, quién ha sido? Si, es cierto, el comando "su" se registra pero ... quién lo ha ejecutado?
# tail /var/adm/sulogBien, es cierto que podemos habilitar la auditoria -que en aquél entonces no estaba, mal, mal, muy mal- pero ... podemos hacer algo más?
SU 09/26 13:07 + pts/5 itily-root
SU 09/26 13:10 + pts/6 zooey-root
La respuesta es SI, activar los roles.
Modelo de Seguridad utilizando Roles
El uso de <roles> dentro de un sistema de seguridad hace posible el concepto de <Administración Delegada>, es decir, imaginemos que tenemos varios perfiles de administradores, unos Junior otros Senior, incluso gente que no sabe Solaris. Podemos pensar de forma rápida en entregar la contraseña de root al administrador Senior, y para los otros solicitar que la introduzca cuando sea necesario.
Bien, a priori puede parecer que con esto hemos solventado el problema de nuestro administrador Junior pero qué sucede cuando no encuentra al administrador Senior? O, mejor aún, qué hace el administrador Senior mientras el Junior administra con root?
Como véis, esto no es operativo, y al final, en el modelo de SuperUser sólo podemos entregar la contraseña de root a los adminstradores Senior y Junior, y establecer algún mecanismo mediante "sudo" o "setuid script" para las tareas importantes.
Si, es cierto, podemos utilizar "sudo" que nos permite ejecutar un comando como root aun no siendo, pero ... si ese comando es gestionar PostgreSQL mediante Solaris SMF. Bueno, aquí la cosa se complica.
Divide y Vencerás
Continuando con nuestro ejemplo de PostgreSQL, podemos definir diferentes tareas y cada una de esas tareas asignarlas a diferentes roles, que, a su vez, asignarlas a diferentes usuarios. Me explico, por ejemplo, definimos las tareas de "Administración de PostgreSQL", "Administración de Tomcat" y "Administración Host".
De esta forma, podemos tener la siguiente tabla:
- Administración PostgreSQL: Iniciar y Detener el Servicio, y ejecutar los comandos de PostgreSQL, pero no configurarlo
- Adminstración Tomcat: Iniciar y Detener el Servicio, pero no configurarlo
- Administración Host: Puede realizar cualquier acción
itily@openzooey:~$ pfexec cat /etc/user_attr | grep postgresSi nos fijamos en el tipo <type> vemos que pone <role>, si no os aparece ninguna entrada, es que habéis eliminado el role. Por el momento, no vamos a hacer caso al valor de <profiles> ya que lo examinaremos en las siguientes entregas.
postgres::::type=role;profiles=Postgres Administration,All
Cómo Crear un Role
Como ya hemos comentado, un role es prácticamente un usuario, y por lo tanto, su forma de crearlo es muy parecida. En vez de utilizar <useradd>, utilizaremos <roleadd> con los mismos parámetros a excepción de <-s< que en vez de <bash, sh, csh> serán <pfbash, pfsh, pfcsh>, veámos un ejemplo
root@openzooey:~# roleadd -s /usr/bin/pfbash -d /export/home/asengine -m asengineA continuación debemos asignarle nuestro role a un usuario, en nuestro caso, será a <zooey>
80 blocks
root@openzooey:~# passwd asengine
New Password:
Re-enter new Password:
passwd: password successfully changed for asengine
root@openzooey:~# usermod -R asengine zooeySi nos logeamos con este usuario, podremos ver los <roles> que tiene asignados, utilizando el comando <roles>
root@openzooey:~# su - zooeyComo véis, no ha sido difícil, verdad? Además, como hemos comentado muchas veces, un <rol> es similar a un usuario, por lo tanto, puedo utilizar los comando <chmod, passwd> para asignar los permisos de forma correcta, por ejemplo:
OpenIndiana SunOS 5.11 oi_147 September 2010
zooey@openzooey:~$ roles
asengine
zooey@openzooey:~$ su - asengine
Password:
OpenIndiana SunOS 5.11 oi_147 September 2010
asengine@openzooey:~$ id
uid=102(asengine) gid=1(other) groups=1(other)
root@openzooey:~# mkdir -p /var/sfchildren
root@openzooey:~# chown -R asengine /var/sfchildren
root@openzooey:~# chmod 700 /var/sfchildren
Cuidado con la asignación de Roles
Debéis tener cuidado con el comando <usermod -R ...> ya que este sustituye no añade roles, es decir, si tenemos el siguiente usuario
root@openzooey:~# roles zooeyY ejecutamos el comando <usermod -R asengine>
root
root@openzooey:~# usermod -R asengine zooeyEl resultado será que hemos perdido el <role> root y en OpenIndiana tendremos un problema, ya que el usuario <root> es un <role> y por lo tanto, no podremos logearnos desde la consola, ya que ahora el usuario <itily> tiene asignado el <rol>asengine> sólamente,
root@openzooey:~# roles zooey
asengine
Para ello, debemos utilizar el comando <usermod -R role1,role2,role...>
root@openzooey:~# usermod -R root,asengine zooey
root@openzooey:~# roles zooey
root,asengine
Jugando con los Roles
Veamos un poco como podemos utilizar los roles de nuestro ejemplo. En este caso, el usuario <zooey> tendrá asignado el <rol> de <postgres> y por lo tanto, podrá ejecutar sus comandos, sin embargo, no podrá administrar nuestro host.
zooey@openzooey:~$ idComo hemos comentado, aunque <zooey> conozca la contraseña de <root> no puede asumirla, ya que su usuario no tiene el derecho para hacerlo.
uid=102(zooey) gid=14(sysadmin) groups=14(sysadmin)
zooey@openzooey:~$ roles
postgres
zooey@openzooey:~$ su - postgres
Password:
OpenIndiana SunOS 5.11 oi_147 September 2010
postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres
psql (9.0.0)
Type "help" for help.
postgres=# \q
zooey@openzooey:~$ su -
Password:
Roles can only be assumed by authorized users
su: Sorry
Qué hemos conseguido
Al utilizar roles, hemos conseguido por un lado, tener controlado el acceso, ya que, ahora podemos asignar el role <postgres> a los usuarios que queremos que tengan la posibilidad de administración.
Además, en el supuesto de "alguien" descubra la contraseña del role <postgres> también necesitará conocer el login y password de un usuario con posibilidad de asumirlo.
Conclusiones
En esta ocasión hemos avanzado un poco más en el modelo de seguridad que nos ofrece Solaris, y, aunque puede parecer complicado no lo es tanto.
En las próximas entregas veremos las <autorizaciones> y con esa última parte, ya tendremos el modelo de seguridad completo.
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 1
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 2
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 3
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 4
Referencias
No hay comentarios:
Publicar un comentario