Modelo de Seguridad de Solaris: RBAC, Roles y Privilegios - Parte 6

Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión, toca hablar de , ya que hemos avanzado en nuestros conceptos del modelo de seguridad de Solaris.

Qué son las Autorizaciones
Una autorización es un privilegio discreto que puede ser asignado a un usuario o un rol, dicho de otro modo, es un privilegio que nosotros definimos sin que por ello deba ir asignado a un privilegio de UNIX. De esta forma, hacemos que la verificación <UID=0> pase a ser secundaria.

No todos los comandos de Solaris aceptan el uso de autorizaciones, actualmente está soportado en:

• Suite Solaris Management Console
  
• Comandos de administración de Auditoria, como auditconfig y auditreduce
  
• Comandos de administración de Impresión, como lpadmin y lpfilter
  
• Comandos de Jobs, como at, atq, batch y crontab
  
• Comandos orientados a dispositivos, como allocate, deallocate, list_devices y cdrw.
  

Nosotros nos vamos a centrar principalmente en los Comandos de SMC y, sobre todo en SMF. Es decir, vamos a utilizar <autorizaciones> para permitir administrar los servicios gestionados por SMF a un <rol> definido por nosotros.

Formato de una autorización
Las autorizaciones se encuentran definidas en el fichero </etc/security/auth_attr> y tienen el siguiente formato:

prefix.suffix:res1:res2:short desc:long desc:attr

Donde

• prefix: Identifica el prefijo, por conveniencia las autorizaciones de Sun Solaris comienzan con <solaris.>, para las nuestras debemos utilizar nuestro Dominio de Internet al revés, por ejemplo, <com.sfchildren.>
• suffix: Sufijo del componente. Cuando una autorización termina con <grant> hacemos que quien posea dicha autorización pueda otorgarla a otros, por ejemplo, teniendo la autorizaciones <solaris.com.sfchildren.asengine.grant y solaris.com.sfchildren.asengine.analyzer>,  si asignamos <solaris.com.sfchildren.asengine.grant>, a un role o usuario, éste podrá asignar la autorización <solaris.com.sfchildren.asengine.analyzer> a otro role o usuario.
• res1 y res2: Campos reservados
• short desc: Descripción corta
• long desc: Descripción larga
• attr: Definición de atributos con el formato <KEY=VALUE>

Por ejemplo,

solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html

Ver las autorizaciones asignadas
Para ver las autorizaciones asignadas a un usuario o role, simplemente deberemos ejecutar el comando <auths [nombre]>, dónde nombre será un role o un usuario, si no ponemos nada, entonces nos mostrará las autorizaciones del usuario actual, por ejemplo:

root@openzooey:~# auths
solaris.*
root@openzooey:~# auths tomcat
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read

Asignar una Autorización
Las autorizaciones pueden ser asignadas a roles o usuarios, para ello utilizaremos el comando <rolemod> o <usermod> con la opción <-A autorizacion1, autorizacion2, autorizacion>.

Esta opción sustituye no añade, por lo tanto, si quereis conservar las actuales, debereis incluirlas. Para eliminar las autorizaciones, simplemente utilizamos la opción <-A "">, por ejemplo:

root@openzooey:~# rolemod -A solaris.org.apache.smf.value.tomcat,solaris.org.apache.smf.manage.tomcat
root@openzooey:~# auths tomcat
solaris.org.apache.smf.manage.tomcat,
solaris.org.apache.smf.value.tomcat,
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read

Veamos un Ejemplo Completo
Vamos a partir de Cómo Instalar Apache Tomcat en Solaris utilizando SMF, para realizar algunos cambios en la instalación, uso de roles y autorizaciones.

En ese post -Instalación de Tomcat- creabamos un grupo y usuario llamado <webrunner>, en esta ocasión, vamos a crear el grupo de igual forma, pero en vez de un usuario llamado <webrunner> vamos a crear un <role> llamado <tomcat6>.

Por lo tanto,  tendremos la siguiente estructura de instalación de Apache Tomcat

• TOMCAT_HOME: /opt/www/tomcat6
• JAVA_HOME: /usr/java
• TOMCAT_USER: tomcat6
• TOMCAT_GROUP: webrunner
• PROJECT_NAME: tomcat6

Creación del Grupo, Project y Role
Como hemos hecho en otras ocasiones, crearemos un grupo, projecto y un role para nuestra instalación

# groupadd webrunner
# roleadd -s /bin/pfbash -d /export/home/tomcat6 -m -g webrunner tomcat6
# projadd -c 'Tomcat6 Project' -G webrunner -U tomcat6 tomcat6
# passwd tomcat6
New Password:  *********
Re-enter new Password:  *********
passwd: password successfully changed for tomcat6

Creación de las Autorizaciones
Vamos a crear las autorizaciones necesarias para la gestión de nuestro servicio Apache Tomcat desde Solaris SMF, para ello, definiremos una para <gestión>, otra para <cambio> y por último nuestro <grant>

Dentro de Solaris SMF, debemos asignar una autorización para la propiedad <action> que nos permitirá gestionar los servicios, y la propiedad <value> para cambiar los valores. Básicamente, si tenemos sólo la autorización para <action> podremos activar/desactivar los servicios, pero "de forma temporal" -es decir utilizando la opción <-t>- ya que no tenemos la autorización <value> para "guardar el cambio"

# echo "solaris.org.apache.smf.value.tomcat:::Change value of Apache Tomcat::" >> /etc/security/auth_attr
# echo "solaris.org.apache.smf.manage.tomcat:::Manage Apache Tomcat service states::" >> /etc/security/auth_attr

La estructura de la autorización utilizada es solaris.org.apache.smf., por un tema de compatibilidad, pero podíamos haber puesto cualquier cadena, por ejemplo,  solaris.org.apache.tomcat6.administrar

Modificación del Manifest
A continuación editaremos nuestro archivo Manifest para Apache Tomcat 6, o bien, podéis bajaros la versión modificada para Apache Tomcat 6 con Autorizaciones de Solaris. Y, aunque el method no ha sido modificado, podéis descargarlo desde Apache Tomcat Method for Solaris SMF

En las sección general añadiremos las siguientes propiedades:

        <property_group name='general' type='framework'>
                <propval
                     name='value_authorization'
                     type='astring'
                    value='solaris.org.apache.smf.value.tomcat' />
                <propval
                    name='action_authorization'
                    type='astring'
                    value='solaris.org.apache.smf.manage.tomcat' />
        </property_group>

Y dentro de nuestra instancia, añadiremos una propiedad llamada <value_authorization> para definir el valor de la autorización.

   <property_group name='tomcat_6' type='application'>
                        <propval name='home' type='astring'
                           value='/opt/www/tomcat-6.0' />
                        <propval name='jvmargs' type='astring'
                           value='-d32 -Xms64m -Xmx128m' />
                        <propval name='project' type='astring'
                           value='tomcat6' />
                        <propval name='java_home' type='astring'
                           value='/usr/java' />
             <propval name='value_authorization' type='astring'
                           value='solaris.org.apache.smf.value.tomcat' />
   </property_group>

Cargar el Nuevo Manifest de Apache Tomcat
Si habéis decidido descargar el nuevo Manifest para Apache Tomcat 6 utilizando Autorizaciones, simplemente deberemos utilizar <wget> y volverlo a cargar. Si, por el contrario lo habéis modificado, sólo será necesario recargarlo con <svccfg>

root@openzooey:/# mkdir -p /var/svc/manifest/application/web/
root@openzooey:/# cd /var/svc/manifest/application/web
root@openzooey:/var/svc/manifest/application/web# wget http://blog.sfchildren.com/blogger/tomcat-roles/smf/tomcat_6.xml
root@openzooey:/var/svc/manifest/application/web# svccfg
svc:> validate tomcat_6.xml
svc:> import tomcat_6.xml
svc:> quit
root@openzooey:/var/svc/manifest/application/web# svcs tomcat_6
STATE          STIME    FMRI
disabled       16:17:08 svc:/application/web/tomcat_6:default_32bits
disabled       16:17:08 svc:/application/web/tomcat_6:default_64bits

Asignar las Autorizaciones
Por último, vamos a asignar las autorizaciones a un usuario que será el encargado de gestionar el servicio, pero no de configurarlo, en nuestro caso, será <webope>

$ id
uid=108(webope) gid=100(webope)
$ auths
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read

Si intentamos activar el servicio <tomcat_6:default_64bits> con el usuario <webope> antes de asignar las autorizaciones, veremos el siguiente error:

webope@openzooey:~$ svcadm enable tomcat_6:default_64bits
svcadm: svc:/application/web/tomcat_6:default_64bits: Permission denied.

Bien, ahora asignaremos las autorizaciones y volveremos a repetir el comando de activación.

root@openzooey:/# usermod -A solaris.org.apache.smf.manage.tomcat,solaris.org.apache.smf.value.tomcat webope
root@openzooey:/# su - webope
OpenIndiana    SunOS 5.11    oi_147    September 2010
webope@openzooey:~$ svcadm enable tomcat_6:default_64bits
webope@openzooey:~$ svcs tomcat_6:default_64bits
STATE          STIME    FMRI
online    16:47:42 svc:/application/web/tomcat_6:default_64bits

Y también podemos desactivar el servicio, utilizando la opción <disable>

webope@openzooey:~$ svcadm disable tomcat_6:default_64bits
webope@openzooey:~$ svcs tomcat_6:default_64bits
STATE          STIME    FMRI
disabled       16:48:40 svc:/application/web/tomcat_6:default_64bits

Conclusiones
Espero que con este ejemplo completo de uso de autorizaciones aplicado al servicio SMF, podáis utilizar un elemento muy interesante en cuanto a sistemas de seguridad granulados.

Tal vez alguno se cuestione el por qué asignar las autorizaciones a un usuario (o role) que no tiene permisos de configuración pero si de inicio y parada, parece una tontería, no? Bueno, la verdad es que si pensamos en sistemas autónomos de monitorización, como por ejemplo, Nagios para Solaris 10, entenderemos que podemos configurar una acción para el estado MAINTANCE que llame a un script que haga un refresh del servicio.

Es cierto que podemos utilizar el usuario del servicio -en nuestro caso tomcat6- pero, si alguien tomase el control de nuestra máquina "nagios" puede hacer mucho daño ...

Además, de esta forma, podemos tener separado el rol de cada uno de nuestros empleados, por ejemplo, Administradores de Sistemas de Operadores, y por lo tanto, dejar a un Operador que haga un "refresh" pero no un "stop" del servicio.

Queda un último punto, que iremos viendo a lo largo de más ejemplos que es Cómo Aplicar Autorizaciones a Scripts y Programas Antiguos


<< 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
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 5
 

RBAC, Roles y Privilegios en Solaris 10 - Parte 7 >>

Referencias

• Apache Tomcat 6 Solaris SMF Manifest con Autorizaciones
• Apache Tomcat 6 Solaris SMF Method
• Roles, Rights and Profiles - Sun Documentation
• Monitorizar Servicios de Solaris con Nagios - Parte 1 
• Instalar Apache Tomcat 6 en Solaris 10 64bits usando SMF
• Instalación de PostgreSQL en OpenIndiana - Parte 1