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

Introducción
En la Primera Parte de RBAC, Roles y Privilegios de Solaris hicimos un pequeño acercamiento a la tecnología. La idea es ir descubriendo estas funciones, pero utilizando pequeños ejemplos para poder mostrar su aplicación en un entorno real y hacerlo más ameno.

Dentro de las opciones disponibles, en este primeros pasos vamos a centrarnos en privilegios, los definiremos y, veremos cómo podemos utilizarlos.

Privilegios en Solaris
Todos los procesos tienen asociados unos privilegios -como vimos en la primera parte- Efectivos (E) que el kernel evaluará antes de ejecutarlo.

Solaris incorpora alrededor de 70 privilegios definidos en varios grupos,  identificados como grupo_nombre_privilegio, por ejemplo:

• FILE: Privilegios de gestión de archivos en sistemas de archivos.
• IPC: Privilegios de gestión y acceso a objetos IPC
• NET: Privilegios de gestión y acceso a funcionalidades de red
• PROC: Privilegios de gestión y acceso a las propiedades restrigidas de los procesos
• SYS: Privilegios de acceso sin restricciones a varias propiedades de sistema

Gestión Básica de Privilegios
Como ya comentamos en la primera parte, para ver los privilegios de un proceso debemos utilizar el comando <ppriv _pid_>, sin embargo, en esta ocasión vamos a utilizar la opción <-l> que nos mostrará los todos los permisos actuales, por ejemplo:

$ ppriv -l|wc -l
      68
$ ppriv -l|head -4
contract_event
contract_observer
cpc_cpu
dtrace_kernel

Roles y Usuarios
El uso de privilegios está indicado principalmente a ser asignados a roles, donde definiremos conjuntos de acciones que puede definir un grupo. Esta definición la llamaremos role, así mismo, un role puede ser adquirido por diferentes usuarios.

Entraremos en más detalle del uso de roles en las siguientes entregas, no te preocupes que poco a poco iremos montando el rompecabezas ...

Añadir Privilegios a un usuarios
Podemos añadir privilegios a un usuario en concreto, es decir, sin tener que utilizar roles. Esto se utiliza principalmente para demonios y/o situaciones muy concretas, para el resto es mejor -y más fácil- utilizar roles.

Para añadir un privilegio a un usuario, utilizaremos el comando <usermod> con la opción <-K> donde asignaremos los privilegios separados por coma, el formato es el siguiente:

# usermod -K defaultpriv=privilege_1,privilege_2,privilege_n username

Por ejemplo, para asignarle privilegios al usuario test con la finalidad de que sea capáz de sincronizar el reloj utilizando el comando <ntpdate> vamos a asignar los privilegios: sys_time (para la hora) y net_privaddr (para poder hacer bind en un puerto inferior a 1024).

Primero comprobaremos los permisos del usuario, posteriormente asignaremos los privilegios y volveremos a probar, vemos el ejemplo:

$ ppriv $$
14617:  -bash
flags =
        E: basic
        I: basic
        P: basic
        L: basic,contract_event,contract_observer,file_chown,file_chown_self,file_dac_execute,
file_dac_read,file_dac_search,file_dac_write,file_owner,file_setid,ipc_dac_read,
ipc_dac_write,ipc_owner,net_bindmlp,net_icmpaccess,net_mac_aware,net_privaddr,
proc_audit,proc_chroot,proc_lock_memory,proc_owner,proc_priocntl,proc_setid,
proc_taskid,sys_acct,sys_admin,sys_audit,sys_mount,sys_nfs,sys_resource,sys_time
$ /usr/sbin/ntpdate hora.rediris.es
 7 Sep 23:52:27 ntpdate[14631]: bind() fails: Permission denied
$ exit
logout
# usermod -K defaultpriv=basic,sys_time,net_privaddr test
UX: usermod: test is currently logged in, some changes may not take effect until next login.
# su - test
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$ /usr/sbin/ntpdate hora.rediris.es
 7 Sep 23:52:42 ntpdate[14647]: adjust time server 130.206.3.166 offset -0.002587 sec
$ ppriv $$
14643:  -bash
flags =
        E: basic,net_privaddr,sys_time
        I: basic,net_privaddr,sys_time
        P: basic,net_privaddr,sys_time
        L: basic,contract_event,contract_observer,file_chown,file_chown_self,file_dac_execute,
file_dac_read,file_dac_search,file_dac_write,file_owner,file_setid,ipc_dac_read,
ipc_dac_write,ipc_owner,net_bindmlp,net_icmpaccess,net_mac_aware,net_privaddr,
proc_audit,proc_chroot,proc_lock_memory,proc_owner,proc_priocntl,proc_setid,
proc_taskid,sys_acct,sys_admin,sys_audit,sys_mount,sys_nfs,sys_resource,sys_time

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

 

Conclusión
En esta ocasión hemos entrado un poco más en el detalle del uso de los privilegios, y aunque con un ejemplo un poco extremo, hemos otorgado privilegios a un usuario normal la posibilidad de modificar la hora del sistema utilizando el comando <ntpdate>. De esta forma, ya no será necesario que tengamos que proporcionarle la password de root.

Referencias

• RBAC, Roles y Privilegios en Solaris 10 - Parte 1
• Roles, Rights and Profiles - Sun Documentation
• Privileges On Solaris 10 - Sun Documentation

Modelo de Seguridad de Solaris: RBAC, Roles y Privilegios

Introducción
En esta ocasión vamos a hacer un repaso -en varias partes- al modelo de seguridad que nos proporciona Solaris y cómo podemos utilizarlos para hacer más seguro nuestro entorno. Ha pasado mucho tiempo desde que empecé el blog, y ahora sí, ya estamos en disposición de poder hablar de esta característica tan potente.

En UNIX el modelo de seguridad se establece como Lectura(r), Escritura(w) y Ejecución(x) para el Propietario, Grupo y Los demás. Un modelo que en un principio era más que suficiente para llevar a cabo las tareas comunes y tener un sistema de seguridad adecuado a las necesidades de aquel tiempo, sin embargo, a día de hoy las cosas son un poco más complicadas.

El modelo UNIX de seguridad, además define que para poder acceder a un puerto inferior a 1024 es necesario tener privilegios de root. Esta medida -en su momento interesante- hace que a día de hoy -con el avance de los exploits, buffer overflow, etc. - pone en riesgo nuestro sistema, veamos un ejemplo.

Un pequeño ejemplo
Nuestro servidor Apache HTTP necesita levantarse en el puerto 80 -y como hemos comentado es necesario tener permisos de root para ello-, por lo tanto, para evitar que todos nuestros procesos de HTTP corran con los permisos de root, nuestro Apache hace un setuid a un usuario no privilegiado para los nuevos procesos de esta forma,  minimiza el posible problema de permisos.  Por ejemplo, si miramos los procesos de nuestro Apache HTTP

www  4076 13484   0 05:17:43 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
root 13484   774   0   mar 25 ?          11:20 /opt/www/apache-1.3.41/bin/httpd

Sin embargo,  sigue quedando un proceso con todos los permisos y es aquí donde podemos tener problemas.


Super User Model
El modelo SuperUser, hace referencia a contar con un usuario "super priviligiado" <root> que no tiene ningún tipo de limitación y de un conjunto de usuarios no privilegiados. Esto supone que no disponemos de un sistema de ajuste fino de asignación, por ejemplo, si queremos que un usuario pueda reiniciar el servicio Apache HTTP, debemos otorgarle permisos de root -o proporcionale la contraseña-, sin embargo, al hacerlo, también le estamos otorgando todos los permisos.


RBAC y Privilegios
Role Based Acces Control, es una evolución introducida en Solaris 8 -hace ya tiempo- para poder gestionar las acciones mediante privilegios. De esta forma, podemos tener un grupo de privilegios para nuestros operadores nivel 1, para que puedan iniciar/detener/checkear el Sistema de monitorización de Nagios, pero que no puedan hacer un reboot de la máquina. Para solucionar este problema, se introdujeron los privilegios y los roles.

• Un privilegio es una definición booleana que permite a un usuario no privilegiado ejecutar una acción o no, por ejemplo, uso de puertos privilegiados, cambiar planificador, etc.
• Un role es una agrupación de privilegios que un usuario puede tomar -si tiene permisos y conoce su contraseña-.

Uso de Roles
La gestión de roles se realiza con los comandos: roleadd, rolemod y roledel. Éstos tienen el mismo formato que la gestión de usuarios (useradd, usermod y userdel) y en el modelo SuperUser, son representados como un usuario, y por lo tanto, podemos utilizar los comandos <passwd> para cambiar la contraseña y <su> para asumir una role.

Una nota importante es que una role siempre tiene como shell a pfsh. Por ejemplo, vamos a ver cómo podemos crear un role de una forma sencilla:

# roleadd -d /export/home/testrole -m testrole
64 bloques
# passwd testrole
Nueva contraseña:
Vuelva a escribir la nueva contraseña:
passwd: la contraseña se ha cambiado para testrole satisfactoriamente
# su - testrole
$ echo $SHELL
/bin/pfsh

Administrar los Privilegios
Para las tareas de administración, disponemos del comando <ppriv> que nos permite ver o modificar los valores de los privilegios o atributos. Por ejemplo, para ver el conjunto de privilegios de nuestro proceso shell haremos lo siguiente:

$ ppriv $$
1046:    -pfsh
flags =
    E: basic
    I: basic
    P: basic
    L: basic,contract_event,contract_observer,file_chown,file_chown_self,file_dac_execute,file_dac_read,file_dac_search,file_dac_write,file_owner,file_setid,ipc_dac_read,ipc_dac_write,ipc_owner,net_bindmlp,net_icmpaccess,net_mac_aware,net_privaddr,net_rawaccess,proc_audit,proc_chroot,proc_lock_memory,proc_owner,proc_setid,proc_taskid,sys_acct,sys_admin,sys_audit,sys_ip_config,sys_mount,sys_nfs,sys_resource

La salida de este comando nos proporciona los siguientes datos:

• Heredados (I): Privilegios heredados en exec
• Permitidos (P): Privilegios máximos del proceso
• Efectivos (E): Privilegios actualmente activos, es un subconjunto de (P)
• Limite (L): Privilegios máximos que un proceso y sus hijos pueden llegar a obtener en el siguiente exec

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

Conclusiones
En esta primera parte, hemos visto la estructura de seguridad de UNIX y cómo han evolucionado hasta llegar a los privilegios y roles en Solaris.

En las siguientes entregas veremos cómo podemos utilizarlos dentro de nuestras instalaciones para garantizar un mayor nivel de seguridad.

Instalar ActiveMQ 5 en Solaris 10 - Parte 2

Introducción
En la primera parte de Instalar ActiveMQ en Solaris, vimos como realizar una instalación por defecto sin mayores complicaciones, sin embargo, en esta ocasión veremos como podemos configurar nuestro ActiveMQ para iniciarlo utilizando un sistema de configuración personalizada.

Además, haremos un pequeño repaso a las opciones más importantes y hablaremos de algunos temas de funcionamiento de JMS, como por ejemplo persistencia.

Configuración ActiveMQ
La configuración de ActiveMQ se puede realizar de varias formas, aunque la más customizable es la que utiliza un archivo xml para ello. El formato de ejecución de ActiveMQ es el siguiente:

$ACTIVEMQ_HOME/bin/activemq {opciones} {config_file}

Si no asignamos ningún valor a config_file ActiveMQ utilizará la configuración por defecto -como hemos utilizado en la primera parte- donde nos crean diferentes transportes y activa la consola de administración

Los TransportConnector
Un transportConnector es la definición del servicio donde queremos que nuestro ActiveMQ escuche, es decir, las uri en los cuales hará binding. Su formato es el siguiente:

<transportconnector name="_nombre_" uri="_protocolo_://_hostname_:_port_" />

Existen diferentes tipos de transportConnector, aunque hoy sólo vamos a hablar de dos tipos TCP y NIO podéis encontrar toda la información en Apache ActiveMQ Transport Connectors.

Nos hemos centrado en estos dos tipos, puesto que son sencillos y nos permiten ver la forma de configuración y algún tipo de optimización al utilizar NIO -recordar que hablábamos de Java NIO en Cómo activar Java NIO en Tomcat 6-

La diferencia principal entre tcp y nio reside en que el formato tcp es bloqueante single thread y que nio es no bloqueante multi threard. Cuando hablamos de bloqueante y no bloqueante hacemos referencia a las peticiones -y a su proceso de dispatcher- que en el caso de utilizar tcp procesará cada petición una detrás de la otra.

Esto supone una penalización cuando utilizamos aplicativos web ya que si una petición se cuelga las demás esperarán hasta que se produzca un TimeOut -o se cancele-, para evitar esto utilizaremos el formato nio que, si una petición -mensaje- se cuelga el dispatcher continuará ejecutando las demás.

Todo esto es una forma resumida de explicar el funcionamiento de ActiveMQ, aunque debemos saber que también depende de si tenemos persistencia o no en nuestro sistema de mensajes. Tienes más información sobre persistencia en la página oficial de ActiveMQ Persistence

Qué es eso de Persistencia
En el universo JMS existen opciones para tratar a los mensajes de forma transaccional -al igual que en una base de datos- y por lo tanto, estos mensajes han de ser salvados a disco de forma atómica. Esto supone que si un mensaje JMS con la opción de persistencia activa se almacenará en un lugar hasta que el cliente -o clientes- han devuelto un ack informándo que lo han procesado correctamente.

Además, esto nos permite que ante una caída de nuestro servidor JMS, los mensajes que no se habían enviado, se vuelvan a enviar a aquellos clientes que no los han obtenido.

Toda esta lógica de control es configurable a nivel de cliente pero en el servidor debemos dotar de los mecanismos para que el cliente los pueda utilizar, me explico. Si nosotros no facilitamos soporte de persistencia, aunque nuestro cliente lo configure no funcionará.

Hay que diferenciar la persistencia de la operatividad del servidor, es decir, mientras esté activo utilizará memoria RAM para procesar y almacenar los mensajes, pero si se cae no sabrá dónde estaba y por lo tanto no volverá a reenviar los mensajes pendientes a menos que tengamos el soporte de persistencia activo

Rendimiento vs Tolerancia a Fallos
Debemos tener en cuenta que a mayor tolerancia, menor rendimiento esto es debido a que al aumentar la tolerancia, estamos habilitando un sistema de persistencia en base de datos, o replicación, y por lo tanto, cada mensaje debe pasar por más etapas para completarlo. En la web de Apache ActiveMQ puedes encontrar diferentes configuraciones y explicaciones sobre estas opciones.

Configuración de Nuestro ActiveMQ
Después de un poco de introducción, veámos como podemos configurar nuestro Apache ActiveMQ para tener una configuración personalizada. Para ello, he recreado los archivo de Solaris SMF Manifest ActiveMQ y Solaris SMF Method ActiveMQ ya que he incluido soporte para cargar un archivo de configuración personalizado.

Recordar que deberemos eliminar y volver a importar el archivo de definición (manifest) para que sea efectivo. Además revisar la configuración de nuestro ACTIVEMQ_HOME para que haga referencia a nuestra ubicación.

El contenido de nuestro archivo de ejemplo de configuración de ActiveMQ es la siguiente:

        <transportConnectors>
            <transportConnector name="open" uri="tcp://0.0.0.0:61616"/>
            <transportConnector name="master" uri="nio://0.0.0.0:61816"/>
            <transportConnector name="slave" uri="nio://0.0.0.0:61916"/>
        </transportConnectors>
        <import resource="activemq-admin-console.xml"/>

Y para activar sólo la consola de administración de Apache ActiveMQ incluiremos el resource en nuestro archivo de configuración.

Con todo esto, ya podemos hacer  empezar con nuestras configuraciones, y hacer las diferentes pruebas para ver cuales nos proporcionan el mejor rendimiento.

Conclusiones
Siguiendo con el post anterior, hemos visto como Apache ActiveMQ nos proporciona numerosas opciones de configuración, y que unido a Solaris SMF podemos tener un servidor estable y potente.

En la siguiente parte, hablaremos de Cómo configurar un Transport SSL y las diferentes formas de conexión en modo FailOver para aumentar la disponibilidad de nuestro servicio.



<< Instalación de Apache ActiveMQ - Parte 1


Referencias

• Instalar Apache ActiveMQ en Solaris 10 - Parte 1
• Problemas con ActiveMQ 5.4 en Solaris 10
• Configuración por defecto de Apache ActiveMQ (xml)
• Activar JavaNIO en Apache Tomcat 6
• Rendimiento de Java NIO en Apache Tomcat 6
• Solaris SMF Manifest para Apache ActiveMQ
• Solaris SMF Method para Apache ActiveMQ
• Archivo configuración ActiveMQ de ejemplo
• Activar sólo consola de administración ActiveMQ

Solaris, OpenSolaris y IllumOS

Introducción
Durante los últimos meses -especialmente desde la compra de Sun por parte de Oracle- ha habido unos cuantos rumores sobre el futuro de Solaris y su versión "Open", OpenSolaris.

Bien, después de muchas preguntas sin respuesta por parte de Oracle, ya tenemos más claro el futuro. OpenSolaris desaparece tal y como lo conocemos, es decir, una comunidad con actualizaciones del código base de Solaris y diferentes distribuciones sobre este código.

Oracle ha dicho que seguirá actualizando, pero que no será de forma continuada y se dará prioridad a Solaris sobre cualquier otra cosa, resumiendo, Oracle publicará en formato binario aquellas innovaciones que desee y cuando "quiera" hará público el código fuente en OpenSolaris.

Si ahora sumamos que el organismo de gobierno de OpenSolaris se ha disuelto -a día 23 de agosto de 2010- queda todo en manos de Oracle, por lo tanto, ya no podemos depender de ellos para seguir avanzado en la comunidad OpenSolaris.

Como esto ya era un secreto a voces, se creó el proyecto IllumOS, que inicialmente quería ser una forma de tener una comunidad libre y totalmente desvinculada de Oracle -en temas de gobierno y gestión- pero unido al código de Solaris. IllumOS se creó "antes" de que Oracle hiciese públicas sus intenciones de "no actualizar el código de Solaris diariamente" y por lo tanto, no se quiso hacer un "fork", pero ahora, con estos anuncios no hay más remedio.

Por lo tanto, tenemos la siguiente situación:

• Solaris. Pertenece a Oracle y será necesario tener una subscripción de soporte para poder utilizarlo y actualizarlo.
• Solaris Express. Pertenece a Oracle y estará enfocado desarrolladores y no requerirá una subscripción
• OpenSolaris. Desaparecerá, creo
• IllumOS. Será una versión de "kernel" compatible con Solaris y completamente OpenSource, con una comunidad "real"

Y Qué pasa con OpenSolaris?
Realmente OpenSolaris nunca ha sido una comunidad "open" tal y como se define, principalmente porque siempre había que pasar el "filtro de Sun/Oracle" y había partes que no eran "Open", por ejemplo LibC. Así que, Oracle simplemente la ha dejado "morir"

IllumOS de qué me servirá?
IllumOS no será una distribución como lo era OpenSolaris, es decir, no habrá una ISO -al menos de momento- sobre la cual poder instalar un host, la idea es tener la parte del "kernel" libre de las ataduras de Oracle para poder innovar.

Por ejemplo, si hacemos una analogía con Linux, tendremos que IllumOS sera el Kernel Project, y sobre él se crearán las diferentes distribuciones, Nexenta, Belenix, Schillix como en Linux son Ubuntu, Debian, RedHat, etc.

Resumiendo, IllumOS es un fork del kernel de OpenSolaris, no de la distribución de OpenSolaris, así que será necesario utilizar una distribución -la que queramos- que nos permita utilizar IllumOS como "kernel" pero diferentes repositorios de paquetes para los binarios

Podré migrar de OpenSolaris a IllumOS?
La pregunta es dificil de responder, inicialmente porque -como ya hemos comentado- IllumOS no es una distribución, por lo tanto, la pregunta más acertada sería:

¿Podré migrar de OpenSolaris a Belenix o Nexenta o Schillix? 

Y en la actualidad no tengo una contestación, aunque me gustaría poder decirte que en un futuro será muy probable, pero ... no lo sé.




Conclusiones
Con este post he querido poner un poco más de luz en el culebrón Oracle-Solaris que estamos viviendo, pero tener en cuenta que algunas son interpretaciones mías y puedo estar confundido, si es así estaré encantado de escuchar y corregir aquello que propongáis.

Sólo como último apunte deciros que yo era de los que estaban a favor de que Oracle comprara Sun, y, aunque creo que para Solaris+Oracle RDBMS será muy importante, no pensaba que Oracle cerraría todo aquello Open que se fue construyendo, además, creo que es una estrategia que no favorece a la comunidad Solaris, porque aquellos que quieran venir, tendrán la excusa perfecta: Para que ir de un entorno cerrado a otro? Por qué no FreeBSD?

Esperemos que Oracle vea en el uso de comunidades abiertas más que un competidor y nos vea como una forma de innovación y difusión


Referencias

• Presentación de IllumOS
• Anuncio de disolución de OGB. Blog de Ben Rockwood
• Explicación de Fork "obligado". Blog de Garret D'Amore

Vuelta de vacaciones, anda cuantos cambios

Introducción
Bueno, después de unas pequeñas vacaciones, ya estamos aquí de nuevo y ... hay muchas cosas nuevas sobre las que hablar.

Durante este tiempo, la muerte "anunciada" de OpenSolaris, la creación del proyecto IllumOS y todas las cuestiones que tenemos sobre "Y ahora qué" van a hacer que esta "Vuelta al Trabajo" sea muy interesante.

Me imagino que como a mí, alguno de vosotros se esté preguntando eso de: Pero ... y ahora qué va a pasar con OpenSolaris? Tenemos que migrar a IllumOS? Y Solaris 11?

Estoy preparando un pequeño resumen con las diferentes entradas de estos temas para, por una parte, dejar claro como está el tema, y por otra, para ver qué es lo que puede pasar.

De momento, os avanzo que ya estoy subscrito a la lista de correo de IllumOS en Castellano <illumos-es@lists.illumos.org> y tambien que soy usuario registrado de IllumOS <Urko.Benito> y os animo a que os suméis a la comunidad a través de su página de IllumOS Project