SafeChildren Banner

Havoc Oracle Solaris Experts

lunes, 27 de septiembre de 2010

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

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 <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: postgres
Password: ********
Roles can oly be assume by authorized users
Login incorrect
Analizando 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.

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/sulog
SU 09/26 13:07 + pts/5 itily-root
SU 09/26 13:10 + pts/6 zooey-root
Bien, es cierto que podemos habilitar la auditoria -que en aquél entonces no estaba, mal, mal, muy mal- pero ... podemos hacer algo más?

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
Como ya comentábamos en Instalar PostgreSQL en OpenIndiana, en Solaris existe ya un <rol> para PostgreSQL llamado <postgres>, podemos comprobarlo si ejecutamos el siguiente comando:
itily@openzooey:~$ pfexec cat /etc/user_attr | grep postgres
postgres::::type=role;profiles=Postgres Administration,All
Si 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.

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 asengine
80 blocks
root@openzooey:~# passwd asengine
New Password:
Re-enter new Password:
passwd: password successfully changed for asengine
A continuación debemos asignarle nuestro role a un usuario, en nuestro caso, será a <zooey>
root@openzooey:~# usermod -R asengine zooey
Si nos logeamos con este usuario, podremos ver los <roles> que tiene asignados, utilizando el comando <roles>
root@openzooey:~# su - zooey
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)
Como 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:
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 zooey
root
Y ejecutamos el comando <usermod -R asengine>
root@openzooey:~# usermod -R asengine zooey
El 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:~$ id
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
Como hemos comentado, aunque <zooey> conozca la contraseña de <root> no puede asumirla, ya que su usuario no tiene el derecho para hacerlo.

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

miércoles, 22 de septiembre de 2010

Instalación de PostgreSQL en OpenIndiana - Parte 1

Introducción
Ya hemos visto Cómo Instalar PostgreSQL en Solaris 10 utilizando los binarios que nos proporciona PostgreSQL, sin embargo, en esta ocasión vamos a ver Cómo Instalar PostgreSQL 9.0 en OpenIndiana

Desde la página de PostgreSQL, podemos descargarnos la versión ya compilada para Solaris 10, sin embargo, esta versión no funciona sobre OpenSolaris y OpenIndiana.

Problemas con los binarios para Solaris 10 en OpenIndiana
El principal problema de los binarios compilados para Solaris reside en el uso de la biblioteca <libssl.so.0.9.7> y <libcrypto.so.0.9.7> que en OpenIndiana son </usr/lib/64/libcrypto.so.0.9.8> y </usr/lib/64/libssl.so.0.9.8>

Es decir, en OpenIndiana -OpenSolaris- tenemos una versión superior, y por lo tanto, cuando verificamos las dependencias del inario utilizando <ldd> vemos que no se encuentran:
# ldd postgres
        libxslt.so.1 =>  /usr/lib/64/libxslt.so.1
        libxml2.so.2 =>  /lib/64/libxml2.so.2
        libpam.so.1 =>   /lib/64/libpam.so.1
        libssl.so.0.9.7 =>       (file not found)
        libcrypto.so.0.9.7 =>    (file not found)
        libgss.so.1 =>   /usr/lib/64/libgss.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        librt.so.1 =>    /lib/64/librt.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        libc.so.1 =>     /lib/64/libc.so.1
        libz.so.1 =>     /lib/64/libz.so.1
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
Pero ... que no cunda el pánico, que es un problema fácilmente solucionable. Tenemos tres opciones para ello, o instalamos la versión anterior de OpenSSL cosa que NO RECOMIENDO, o compilamos nuestra propia versión de PostgreSQL o ... podeis descargaros la versión compilada por mí, para OpenIndiana x86 en 64bits de PostgreSQL 9.0.

Si os habéis decidido por la última opción -Instalar PostgreSQL desde el binario par a OpenIndiana-, entonces, podéis ignorar el paso de compilación pero debéis tener en cuenta lo siguiente:
  • El binario debe ser instalado en </u01/app/postgres/9.0/db
  • Utilizaremos el role de <postgres> del sistema
  • El <PGDATA> esta en </var/postgres/9.0/data>
Preparación del Entorno
Antes de poder compilar PostgreSQL 9.0 en OpenIndiana, debemos tener en cuenta que son necesarios algunos paquetes, para ello, deberemos instalarlos antes.

Aquí os dejo la lista de paquetes necesarios, para instalarlos, simplemente debemos ejecutar <pkg install _nombre_paquete_>
  • sunstudio
  • SUNWgmake
  • SUNWbison
  • SUNWgm4
  • SUNWflexlex
Podemos comprobar si ya están instalados utilizando el comando <pkginfo>, por ejemplo
# pkginfo |grep flex
system      SUNWflexlex               Flex Lexer
system      SUNWrsync                 rsync - faster, flexible replacement for rcp
# pkginfo |grep bison
system      SUNWbison                 bison - A YACC Replacement
# pkginfo |grep gm4
system      SUNWgm4                   GNU m4
# pkginfo |grep gmake
system      SUNWgmake                 gmake - GNU make
# pkginfo |grep sunstudio
application sunstudio12u1             Sun Studio 12 update 1

Compilar PostgreSQL 9.0
Para la compilación he utilizado los mismos parámetros que Bjorn Munch utiliza en la versión "oficial" que es posible descargar desde PostgreSQL.

Lo primero que haremos, será descargarnos el fuente de PostgreSQL desde su página oficial, en cualquiera de los dos formatos: tar.gz, tar.bz2
# export CC=cc  
# export CFLAGS="-xO3  -xspace -Xa  -xildoff  -m64  -xc99=none -xCC -fast -native"
# export LDFLAGS="-R/usr/sfw/lib/64 -R/usr/lib/64"
# ./configure 
--prefix=/u01/app/postgres/9.0/db
--exec-prefix=/u01/app/postgres/9.0/db
--bindir=/u01/app/postgres/9.0/db/bin/64
--libexecdir=/u01/app/postgres/9.0/db/bin/64
--sbindir=/u01/app/postgres/9.0/db/bin/64
--datadir=/u01/app/postgres/9.0/db/share
--sysconfdir=/u01/app/postgres/9.0/db/etc
--mandir=/u01/app/postgres/9.0/db/man
--libdir=/u01/app/postgres/9.0/db/lib/64
--includedir=/u01/app/postgres/9.0/db/include
--sharedstatedir=/var/postgres/9.0
--localstatedir=/var/postgres/9.0
--enable-nls
--docdir=/u01/app/postgres/9.0/db/doc
--with-system-tzdata=/usr/share/lib/zoneinfo
--with-python
--with-pam
--with-openssl
--with-libedit-preferred
--with-libxml
--with-libxslt
--with-gssapi
--enable-thread-safety
--enable-dtrace
--disable-integer-datetimes
--with-includes=/usr/include:/usr/sfw/include
--with-libs=/lib/64:/usr/lib/64:/usr/sfw/lib/64
# make
# make install
Configuración de PostgreSQL
A diferencia del post sobre Cómo Instalar PostgreSQL 8.x en Solaris 10, en esta ocasión vamos a utilizar roles para ejecutar el servicio.

Ahora si que estamos en disposición de poder hablar de esta forma de instalación, ya que hemos introducido los conceptos de RBAC, Roles y Privilegios en post anteriores.

No es que la instalación de PostgreSQL 8.x en Solaris 10 no estuviese bien, sino que no utilizaba todos los mecanismos que Solaris nos proporciona -a nivel de seguridad-, para que os hagáis una idea, si ejecutamos el comando <ppriv> sobre el proceso de postgres ejecutado con un usuario normal veremos cuáles son sus privilegios
$ svcs -p postgresql_84
STATE          STIME    FMRI
disabled       mar_04   svc:/application/database/postgresql_84:default_32bit
online         jul_06   svc:/application/database/postgresql_84:default_64bit
               jul_06       3082 postgres
               jul_06       3084 postgres
               jul_06       3085 postgres
$ ppriv 3082
3082:   /u01/app/postgres/8.4/db/bin/64/postgres -D /var/postgres/8.4/data
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
Ahora, si ejecutamos el servicio postgres mediante <pg_ctl> y el role <postgres> veremos la diferencia de privilegios:
$ id
uid=90(postgres) gid=90(postgres)

$ pg_ctl start -l /var/log/postgres/server.log
server starting
$ ps -ef|grep postgre
postgres   794     1   1 09:39:22 pts/1       0:00 /u01/app/postgres/9.0/db/bin/64/postgres
postgres   799   794   0 09:39:22 ?           0:00 /u01/app/postgres/9.0/db/bin/64/postgres
$ ppriv 794
794:    /u01/app/postgres/9.0/db/bin/64/postgres
flags = PRIV_PFEXEC
        E: basic
        I: basic
        P: basic
        L: all
Como podéis ver, la diferencia se encuentra en flags que ahora indica PRIV_PFEXEC ya que al ser un role, su shell es <pfexec> y, si es lanzado por el servicio SMF, es root quien lo lanza.

Además, si queríamos que un usuario -persona- pudiese gestionar nuestro PostgreSQL debíamos entregarle la contraseña de root ya que sino, no podría operar con SMF. Si lo intentase, nos mostraría el siguiente error:
$ id
uid=101(postgres) gid=90(postgres)
$ /usr/sbin/svcadm disable svc:/application/database/postgresql_84:default_64bit
svcadm: svc:/application/database/postgresql_84:default_64bit: Permiso denegado.
Configuración de PostgreSQL en SMF
A continuación configuraremos nuestro servicio postgres para que sea controlado mediante SMF, para ello, debemos descargar el Manifest para Solaris SMF 10 PostgreSQL 9 y el Method para Solaris SMF 10 PostgreSQL 9
# cd /lib/svc/method
# wget http://blog.sfchildren.com/blogger/openindiana/postgresql/9.0/smf/postgres_9
# chown root:bin postgres_9
# chmod 555 postgres_9
# mkdir -p /var/svc/manifest/application/database
# cd /var/svc/manifest/application/database
# wget http://blog.sfchildren.com/blogger/openindiana/postgresql/9.0/smf/postgresql_9.xml
# svccfg
svc:> validate postgresql_9.xml
svc:> import postgresql_9.xml
svc:> quit
# svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:24:40 svc:/application/database/postgresql_9:default_64bit
Creación Estructura de PGDATA
Antes de poder iniciar postgres debemos crear la estructura de almacenamiento necesaria, para ello, deberemos ejecutar el comando <initdb> con los parámetros oportunos. En nuestro caso, vamos a iniciar la estructura en formato <UTF-8> y lenguage <es_UTF8> y la opción <-W> para que nos solicite la password que vamos a asignar al usuario postgres de la base de datos
# mkdir -p /var/postgres/9.0/data
# chown -R postgres:postgres /var/postgres
# chmod 700 /var/postgres
# su - postgres
$ export PGDATA=/var/postgres/9.0/data
$ /u01/app/postgres/9.0/db/bin/64/initdb -E utf8 --locale=es.UTF-8 -U postgres -W
Project y Directorio de Logs
Al igual que hicimos con la Instalación de PostgreSQL en Solaris, debemos definir un project y un directorio donde queremos escribir nuestro log. En nuestro caso, el project será <group.postgres> y el directorio </var/log/postgres>
# projadd -c "Postgres Database" -G postgres group.postgres
# projmod -sK "process.max-sem-nsems=(priv,256,deny)" group.postgres
# projmod -sK "project.max-sem-ids=(priv,100,deny)" group.postgres
# projmod -sK "project.max-shm-ids=(priv,100,deny)" group.postgres
# projmod -sK "project.max-shm-memory=(priv,8G,deny)" group.postgres
# mkdir -p /var/log/postgres
# chown -R postgres:postgres /var/log/postgres
# chmod 700 /var/log/postgres
Inicio y Parada de PostgreSQL
Como siempre, vamos a utilizar el framework de Solaris SMF para gestionar el inicio y parada de PostgreSQL, sin embargo, en esta ocasión -a parte de poder utilizar root- podemos utilizar el role <postgres> para gestionarlo, por ejemplo:
$ id
uid=90(postgres) gid=90(postgres)
$ svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled        9:38:51 svc:/application/database/postgresql_9:default_64bit
$ pfexec /usr/sbin/svcadm enable svc:/application/database/postgresql_9:default_64bit
$ svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
online          9:55:13 svc:/application/database/postgresql_9:default_64bit
                9:55:13      817 postgres
                9:55:13      819 postgres
                9:55:13      820 postgres
                9:55:13      821 postgres
                9:55:13      822 postgres
$ ppriv 817
817:    /u01/app/postgres/9.0/db/bin/64/postgres -D /var/postgres/9.0/data
flags =
        E: basic
        I: basic
        P: basic
        L: all
Otorgar privilegios de administración de PostgreSQL a un usuario
Como hemos comenteado, al utilizar roles podemos delegar privilegios de administración a un usuario cualquiera sin que tengamos que proporciona la contraseña de root.

Por ejemplo, vamos a crear un usuario no privilegiado llamado <zooey> al cual, le vamos a otorgar permisos para poder administrar nuestro servicio PostgreSQL asignándole el role<postgres> y las autorizaciones <solaris.smf.value.postgres> y <solaris.smf.manage.postgres>
# useradd -g sysadmin -s /bin/bash -d /export/home/zooey -m -R postgres -A solaris.smf.manage.postgres,solaris.smf.value.postgres zooey
80 blocks
# passwd zooey
New Password:
Re-enter new Password:
passwd: password successfully changed for zooey
# su - zooey
OpenIndiana     SunOS 5.11      oi_147  September 2010
zooey@openzooey:~$ roles
postgres
zooey@openzooey:~$ pfexec svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:24:40 svc:/application/database/postgresql_9:default_64bit
zooey@openzooey:~$ pfexec /usr/sbin/svcadm enable svc:/application/database/postgresql_9:default_64bit
zooey@openzooey:~$ pfexec svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
online         10:39:25 svc:/application/database/postgresql_9:default_64bit
               10:39:24     1016 postgres
               10:39:24     1018 postgres
               10:39:24     1019 postgres
               10:39:24     1020 postgres
               10:39:24     1021 postgres
zooey@openzooey:~$ pfexec /usr/sbin/svcadm disable svc:/application/database/postgresql_9:default_64bit
zooey@openzooey:~$ pfexec svcs postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:43:51 svc:/application/database/postgresql_9:default_64bit
Conclusiones
En esta ocasión hemos utilizado muchos más mecanismos para gestionar el servicio de PostgreSQL y, hemos aprendido a utilizar los roles como una herramienta muy potente y segura.

Aunque inicialmente la Instalación de PostgreSQL puede ser de la forma tradicional -utilizando un usuario no privilegiado y root para gestionarlo- Solaris nos proporciona un entorno mucho más seguro y rico para ello.

Espero que con este ejemplo -completo- de instalación podáis ver la potencia de los roles, y como nos pueden ayudar en nuestro día a día.

 
Referencias

domingo, 19 de septiembre de 2010

OpenIndiana, El sucesor de OpenSolaris

Introducción
Hace un tiempo hablábamos de la oscura situación de OpenSolaris y su incierto futuro. En aquél entonces hablábamos de Solaris, OpenSolaris e IllumOS.

Después de un tiempo de incertidumbre, ya tenemos algunas respuestas a las preguntas que dejábamos abiertas, principalmente, ¿y ahora qué? Bueno, pues la respuesta es: OpenIndiana


Qué es OpenIndiana
Es una proyecto dentro del nucleo de IllumOS que pretende ser "el sucesor de OpenSolaris", y por lo tanto, OpenIndiana es una distribución completa, es decir, es un sistema instalable.

Para ir abriendo boca
Después de unas pruebas, creo que OpenIndiana es una opción muy interesante, y aunque todavía no hemos visto nada, poco a poco, iremos entrando en materia de Cómo migrar desde OpenSolaris a OpenIndiana, ... pero ante entonces aquí os dejo el banner de OpenIndiana
# cat /etc/release
                      OpenIndiana Development oi_147 X86
        Copyright 2010 Oracle and/or its affiliates. All rights reserved.
                        Use is subject to license terms.
                           Assembled 14 September 2010

Conclusiones
Después de un tiempo, ya tenemos las respuestas a nuestras preguntas y dudas. Ahora, toca hacer las pruebas y ver cómo avanza el proyecto, que, esperemos que se consolide como una alternative real a Solaris 11 y con una comunidad abierta y real -no como sucedía en OpenSolaris-

En los próximos días, veremos Cómo migrar de OpenSolaris a OpenIndiana y Los primeros pasos en OpenIndiana.



Referencias

jueves, 16 de septiembre de 2010

Problemas ActiveMQ 5.4 en Solaris 10

Introducción
Mientras hablábamos de Cómo Instalar Apache ActiveMQ 5.x en Solaris 10, desde Apache han liberado una nueva versión, la 5.4. En esta han introducido algunos cambios, principalmente en los scripts de arranque. Esto hace que las definiciones de los method para ActiveMQ que habíamos creado, ya no funcionen correctamente.

Nuevo formato Script ActiveMQ
El nuevo formato de script acepta más parámetros, y ahora podemos utilizar para iniciar, detener, verificar mensajes, eliminar mensajes, entre otros

El formato es el siguiente
$ACTIVEMQ_HOME/bin/activemq [tarea] [opciones-tarea] [datos-tarea]
Y las tareas disponibles son las siguientes:
  •     start. Crea he inicia el broker
  •     create. Crea una instancia en el path especificado
  •     stop. Detiene el broker
  •     list. Muestra los brokes que hay disponibles
  •     query. Consulta una propiedad de un broker
  •     browse. Muestra los mensajes de un broker
  •     journal-audit. Muestra los mensaje almacenados en el storage area
  •     purge. Borra los destinos seleccionados
Problemas con el script y nuestro method
El principal problema de nuestro method para ActiveMQ 5.3.x viene por el nuevo formato, que ahora es necesario introducir un nuevo parámetro <task>, como hemos visto antes, que nos permitirá realizar diferentes acciones.

Cuando diseñe el method, el script <activemq> no tenía estos parámetros, y por lo tanto, no funcionaba. Para ello, he creado una nueva versión de Solaris SMF Method para ActiveMQ 5.4.x que, simplemente modifica los parámetros de inicio. Así mismo, el manifest para ActiveMQ 5.4 también lo he modificado para que pueda adaptarse a estas nuevas funcionalidades.

Para evitar, tener problemas con mi instalación de ActiveMQ 5.3.x, hemos definido un nuevo ACTIVEMQ_HOME para la instalación ActiveMQ 5.4 que corresponde a </opt/www/activemq5.4> pero puedes asignar la que quieras.

Aplicar el parche de <$ACTIVEMQ/bin/activemq>
He creado un pequeño parche que soluciona los problemas para poder ejecutarlo dentro de nuestra instalación de Solaris.

Básicamente, el problema viene por el uso del comando <whoami> que, como recordáis durante la Instalación de Hadoop en Solaris 10, también nos sucedía, y por el uso de la opción <-q> -quiet- del comando <grep> que en SRV no está definida.
 
Para aplicarlo, simplemente deberemos descargarnos el parche para Solaris 10 de ActiveMQ 5.4 y ejecutar el comando <patch> de la siguiente forma:
# cd $ACTIVEMQ_HOME
# cd bin
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/activemq/5.4/activemq.patch
# patch activemq-test < activemq.patch
  Parece un diff normal.
terminado
Para aquellos que no os apetezca parchear os he dejado una versión Parcheada para Solaris 10 del script que simplemente deberéis remplazar la que viene con la distribución de Apache por esta.

Conclusiones
A veces, los cambios pueden ocasionarnos problemas, por eso, es muy recomendable utilizar un entorno de pruebas donde hagamos todos los cambios, y una vez validados, poderlos pasar a producción.

Además, como no son muy complejos, podemos continuar con nuestra serie de Instalación y Configuración de ActiveMQ 5.x en Solaris 10

Referencias

lunes, 13 de septiembre de 2010

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

Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión vamos a ver el privilegio sys_priocntl -aplicado a una zona- que nos permite modificar el planificador de un proceso desde una zona no global

Modificación del planificador en una Zona No Global
Si intentamos ejecutar el comando de cambio de planificador <priocntl> en una zona no global con los privilegios default Solaris nos mostrará un mensaje de error indicando que no tiene permisos, vamos a verlo:
# zonename
testzone
# ps -cf -u smmsp
     UID   PID  PPID  CLS PRI    STIME TTY         TIME CMD
   smmsp  9046  8589  FSS  59 11:44:15 ?           0:00 /usr/lib/sendmail -Ac -q15m
# priocntl -s -c FX -i pid 9046
Permissions error encountered on pid 9046.

Privilegios Zona No Global para cambiar los planificadores
Vamos a ver cómo podemos hacer para habilitar la administración de planificadores en una zona no global, para ello, deberemos incluir el privilegio sys_priocntl
# zonecfg -z testzone
zonecfg:testzone> set limitpriv=default,proc_priocntl,sys_time
zonecfg:testzone> verify
zonecfg:testzone> commit
zonecfg:testzone> exit
# zoneadm -z testzone reboot

Ahora, al conectarnos a la zona y volveremos a ejecutar el comando de cambio de planificador y le asignaremos TS en vez de FSS y veremos el resultado
# ps -cf -u smmsp
     UID   PID  PPID  CLS PRI    STIME TTY         TIME CMD
   smmsp 13064 12635  FSS  29 13:33:58 ?           0:00 /usr/lib/sendmail -Ac -q15m
# priocntl -s -c TS -i pid 13064
# ps -cf -u smmsp
     UID   PID  PPID  CLS PRI    STIME TTY         TIME CMD
   smmsp 13064 12635   TS  52 13:33:58 ?           0:00 /usr/lib/sendmail -Ac -q15m
Esta vez si que hemos podido cambiar nuestro planificador.

Conclusiones
Hemos visto un privilegio bastante útil que nos permitirá modificar los planificadores -y por lo tanto optimizar el uso- de los procesos que se encuentran dentro de una zona, sin tener que acceder a través de la zona global para ello.

Con esta última parte, ya podemos pasar a las siguientes secciones, donde hablaremos de Roles y, como hemos hecho hasta ahora, utilizaremos pequeños ejemplos para poder explicarlo de forma más sencilla.

<< 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


Referencias

viernes, 10 de septiembre de 2010

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

Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión vamos a ver el privilegio sys_time -aplicado a una zona- que nos permite modificar el reloj del sistema desde una zona no global

Creación de la Zona No Global
Vamos ver esta funcionalidad, para ello vamos a crear una Zona en Solaris 10 utilizando los privilegios por defecto, y comprobaremos cómo no al intentar acceder al reloj del sistema desde la zona -utilizando ntp- nos mostrará un error de acceso denegado, así:
Can't set time of day: Not owner
Puedes encontrar información en este post sobre Cómo Gestionar Zonas en Solaris y sus comandos básicos si tienes dudas. A continuación os muestro la configuración de la zona, para que observéis como no tiene ningún tipo parámetro extraño utilizando el comando <zonecfg -z _nombre_zona info>
# zonecfg -z testzone info
zonename: testzone
zonepath: /opt/zones/testzone
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
inherit-pkg-dir:
        dir: /lib
inherit-pkg-dir:
        dir: /platform
inherit-pkg-dir:
        dir: /sbin
inherit-pkg-dir:
        dir: /usr
net:
        address: 192.168.1.178/24
        physical: eri0
        defrouter: 192.168.1.254
Configuración de NTP sobre una Zona No Global
Vamos a ver Cómo activar la sincronización de Reloj con NTP en Solaris 10 dentro de una Zona, sin haber modificado los privilegios de la misma, vamos a verlo
# echo "server hora.rediris.es" > /etc/inet/ntp.conf
# svcadm enable ntp
# svcs ntp
STATE          STIME    FMRI
online         11:29:42 svc:/network/ntp:default
# dmesg |tail
Sep  6 11:29:42 testzone ntpdate[10804]: [ID 471322 daemon.error] Can't set time of day: Not owner
Sep  6 11:29:42 testzone xntpd[10872]: [ID 702911 daemon.notice] xntpd 3-5.93e+sun 03/08/29 16:23:05 (1.4)
Sep  6 11:29:42 testzone xntpd[10872]: [ID 272427 daemon.error] sched_setscheduler(): Not owner
Como vemos, el servicio <ntp> no ha podido sincronizar la hora del sistema, porque no dispone de privilegios para hacerlo.
 
Configuración de la Zona No Global: Añadiendo el Privilegio sys_time
Para permitir que una zona no global pueda acceder al reloj del sistema y modificarlo, es necesario incluir en el set de privilegios sys_time, además de los privilegios default. Para ello, utilizaremos la propiedad limitpriv y asignaremos los valores: default y sys_time
# zonecfg -z testzone
zonecfg:testzone> set limitpriv=default,sys_time
zonecfg:testzone> verify
zonecfg:testzone> commit
zonecfg:testzone> exit
# zoneadm -z testzone reboot
# zlogin testzone

# zonename
testzone
# ntpdate hora.rediris.es
 6 Sep 11:45:13 ntpdate[9280]: adjust time server 130.206.3.166 offset 0.007079 sec
# svcadm enable ntp
# svcs ntp
STATE          STIME    FMRI
online         12:02:13 svc:/network/ntp:default
# dmesg|tail
Sep  6 12:02:13 testzone xntpd[9831]: [ID 301315 daemon.notice] tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100
Sep  6 12:02:13 testzone xntpd[9831]: [ID 266339 daemon.notice] using kernel phase-lock loop 0041, drift correction 0.00000
Como vemos, en esta ocasión el comando <ntpdate> no ha producido un error de privilegios -puesto que le hemos asignado el privilegio sys_time en la zona- y nos ha permitido cambiar la hora del sistema desde una zona no global




<< RBAC, Roles y Privilegios en Solaris 10 - Parte 1
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 2 




Conclusiones
Continuando con nuestra serie de artículos, hoy a tocado el turno a un nuevo privilegio que nos permite acceder al cambio de hora desde una zona no global. Podemos utilizar este sistema para mantener una zona que acceda a un servidor de hora interno y esté fuertemente protegida -utilizando IP Exclusive e IPFilter- ya que la hora del sistema es un tema muy importante y debemos tener muy protegido.


Referencias

miércoles, 8 de septiembre de 2010

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



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

domingo, 5 de septiembre de 2010

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



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.