SafeChildren Banner

Havoc Oracle Solaris Experts

jueves, 28 de octubre de 2010

Nuevos Tiempos, Nuevo Trabajo, Nuevas Historias

Despedida
Hace un tiempo que quería escribir esta entrada, pero por una cosa o por otra, siempre acababa dejándolo para luego. Bien, el luego ya ha llegado y hoy he decidido "dejar al lado el tema de Solaris" para despedirme de mis compañeros de MasterD.

Si, he cambiado de trabajo, y la verdad es que después de cinco años de trabajo con ellos, lo cierto es que los voy a echar de menos. Echaré de menos esos marrones que -aunque siempre complicados- conseguiamos solucionarlos poniendo nuestro esfuerzo y sobre todo, nuestro compañerismo.

No os voy a aburrir sobre las miles de anécdotas que he acumulado en este tiempo, pero si que os puedo decir que las personas con las que he compartido este tiempo, son más que simples compañeros de trabajo.

Realmente, creo que todo este tiempo hemos sido una pequeña familia -con nuestros más y nuestros menos- pero que siempre hemos estado ahí para cualquier cosa, aunque no tuviese nada que ver con nuestro área de trabajo. No nos importaba "remamgarnos" y, "ale", a ver cómo lo solucionamos.

Y ahora qué
Pues ahora, comienzo una nueva andadura en Havoc Tec, una consultora especializa en Seguridad, Solaris y PostgreSQL. Espero que en esta nueva historia, también pueda escribir comenatrios así algún día.

Havoc Tec - www.havoctec.com
Aunque es un proyecto muy joven, tiene muchas de las cosas que considero interesantes: Solaris, Hadoop, PostgreSQL. Por ello, y, por qué no, porque soy uno de los socios fundadores, creo que será una experiencia muy gratificante.

Ya no os aburro más, y os prometo que seguiré contando historias de Solaris, PostgreSQL y Hadoop durante mucho tiempo ... :D

Por último, quiero despedirme de mis compañeros de trabajo, Luis, Javi, Ricardo, Victor, J, Vero, Sara, Julio alias "el becario", Ana, Pedro, Fermín, Cristian y especialmente de Nazareth. Para los que habéis abandonado el barco antes que yo, también os deseo lo mejor, Marcos y Luisito.

Ha sido un placer trabajar con vosotros,
Urko Benito

lunes, 18 de octubre de 2010

Cómo ver las estadísticas de Memoria en Solaris

Introducción
Ya hemos hablado en varias ocasiones de la swap y Cómo ampliar el tamaño swap en Solaris. Sin embargo, en esta ocasión vamos a ver Cómo se reparte nuestra memoria del sistema.

Para ello, utilizaremos el comando <mdb> con la opción <-k> para depurar nuestro kernel. Realmente, <mdb> es un debugger, y vamos a llamar a <::memstat> para que nos muestre la distribución de la memoria en nuesto sistema vivo
root@openzooey:~# mdb -k
Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba fctl stmf stmf_sbd lofs random idm sd ipc crypto sppp cpc fcip nfs ufs logindmux ptm ]
> ::memstat
Page Summary        Pages            MB  %Tot
------------     --------  ------------  ----
Kernel              73508           287   28%
ZFS File Data       69386           271   27%
Anon                82635           322   32%
Exec and libs        2169             8    1%
Page cache           9139            35    4%
Free (cachelist)     7849            30    3%
Free (freelist)     15296            59    6%

Total              259982          1015
Physical           259981          1015
> ^D

Referencias

sábado, 16 de octubre de 2010

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
 



Referencias

martes, 12 de octubre de 2010

Cómo Cambiar el TimeOut de arranque en OpenIndiana

Introducción
OpenIndiana al igual que OpenSolaris utiliza GRUB para iniciar el sistema. Sin embargo, debemos tener en cuenta el tipo de instalación en OpenIndiana, ya que si utilizamos ZFS como sistema de ficheros la ubicación del archivo de configuración para GRUB será diferente.

Si tenemos UFS como sistema de ficheros, encontraremos el archivo de configuración en </boot/grub/menu.lst>

Si tenemos ZFS como sistema de ficheros, entonces el archivo de configuración se encontrará en </{pool}/boot/grub/menu.lst>

Ya que OpenIndiana el sistema de ficheros es ZFS, vamos a ver cómo podemos editar nuestro <boot.lst>, para ello, primero vamos a identificar nuestro pool -en nuestro caso será rpool1-
urko@openzooey:~$ pfexec /usr/sbin/zpool list
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool1  15,9G  9,96G  5,91G    62%  1.00x  ONLINE  -
Por lo tanto, deberemos editar nuestro
urko@openzooey:~$ pfexec vi /rpool1/boot/grub/menu.lst
  splashimage /boot/grub/splash.xpm.gz
  background 215ECA
  default 1
  timeout 5

 :wq

Conclusión

La única diferencia que existe se encuentra en el formato de sistema de ficheros, pero una vez superado eso, ya podemos editar nuestro sistema de configuración <menu.lst> de la misma forma de siempre.

Referencias

jueves, 7 de octubre de 2010

Instalar OpenIndiana desde OpenSolaris

Introducción
Cuando se anunció IllumOS, hablábamos de Cómo sería el futuro de OpenSolaris y Si existiría una forma de migrar desde OpenSolaris. Posteriormente, nace OpenIndiana una distribución de OpenSolaris que quiere tomar el relevo de éste.

Bien, después de unos días ya podemos decir que la migración de OpenSolaris a OpenIndiana es fácil, sencilla y rápida, por eso, hoy hablaremos de ello.

Lo primero, vamos a utilizar una instalación limpia de OpenSolaris realizada utilizando el Instalador de Texto como ya hablábamos en Cómo Instalar OpenSolaris desde Consola, para, posteriormente actualizarnos a la última versión de OpenIndiana.

El único requisito que existe, es que debemos tener conexión a Internet, ya que el upgrade se realiza utilizando IPS -paquetes de repositorios- y por lo tanto, es necesario

  • Conexión a Internet
  • Tener una "réplica" del repositorio IPS en local

Para hacer más sencillo el paso, he decidido hacerlo desde el repositorio principal de OpenIndiana, aunque volveremos a retomar el tema de Cómo montar un repositorio IPS Local en un futuro.

Instalación de OpenSolaris
Como he comentado en la introducción, vamos a utilizar una instalación de OpenSolaris siguiendo el post que escribí de Cómo Instalar OpenSolaris desde Consola. Una vez instalado, y con conexión a la red, podemos proceder con la actualización.

Instalación de OpenIndiana
Durante el proceso de instalación de OpenIndiana, el sistema nos creará un nuevo boot, por lo tanto, debéis tener en cuenta el espacio disponible en vuestro sistema.

Una vez nuestro sistema OpenSolaris esté online, verificamos que tenemos la versión svn_134 ya que esto nos facilitará bastante las cosas.
urko@openzooey:~$ cat /etc/release
                       OpenSolaris Development snv_134 X86
           Copyright 2010 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 01 March 2010
Verificamos que nuestro usuario tiene el rol de root -recordar el Uso de Roles y Privilegios en Solaris- o nos cambiamos a root
urko@openzooey:~$ roles
root
Actualizamos nuestro OpenSolaris, este comando, si nos encontramos en la versión svn_134 no informará que "no hay nada que actualizar", si estuviésemos en otra inferior, actualizaría los paquetes necesarios.
urko@openzooey:~$ pfexec pkg image-update
No updates available for this image.  

Añadir los "publisher" de OpenIndiana
Debemos añadir los repositorios de OpenIndiana desde los cuales nuestro sistema actulalizará los paquetes, además y muy importante "no debemos eliminar el repositorio de OpenSolaris" ya que, los paquetes que no se encuentren en OpenIndiana, se buscarán en OpenSolaris.
urko@openzooey:~$ pfexec pkg set-publisher --non-sticky opensolaris.org
urko@openzooey:~$ pfexec pkg set-publisher -P -O http://pkg.openindiana.org/dev openindiana.org

Lanzamos <image-update>
Una vez nuestro catálogo se encuentra actualizado, volveremos a lanzar el comando de actualización, y sí, en esta ocasión nos dirá que hay actualizaciones.

El proceso de actualización son unos 300Mb, así que tardará un poquito ...
urko@openzooey:~$ pfexec pkg image-update -v
Solver: [ Variables: 871 Clauses: 5072 Iterations: 2 State: Succeeded]
Timings: [phase 1:  0.993, phase 2:  0.016, phase 3:  9.573, phase 4:  1.953, phase 5:  0.005]
Maintained incorporations: None

Package version changes:

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                              431/431 17037/17037  241.5/241.5

PHASE                                        ACTIONS
Removal Phase                              7356/7356
Install Phase                            12612/12612
Update Phase                             17674/17674

A clone of opensolaris exists and has been updated and activated.
On the next boot the Boot Environment opensolaris-1 will be mounted on '/'.
Reboot when ready to switch to this updated BE.

Reboot del Sistema
Una vez finalizada la actualización, se nos informa que se ha creado un nuevo boot llamado "opensolaris-1" y que será montado en "/" -es decir, se activará-

Para ello, deberemos rebootar la máquina "utilizando el comando <init 6>
urko@openzooey:~$ pfexec init 6

Después del boot
Una vez el sistema se ha iniciado, podemos comprobar cómo ahora ya no es OpenSolaris, sino OpenIndiana haciendo una Verificación versión de Solaris
urko@openzooey:~$ 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
Vemos cómo el proceso de actualización ha mejorado mucho desde los primeros días de vida de OpenIndiana. He optado por esperar para tener la seguridad de que todo fuese bien y así ha sido en muchas actualizaciones -ya he migrado mis OpenSolaris a OpenIndiana :D-

El único inconveniente -como en OpenSolaris- es la necesidad de tener conexión a Internet, pero espero que con el post de Cómo crear un repositorio de OpenIndiana se solucionen esos problemas.

Referencias

domingo, 3 de octubre de 2010

Cómo Limitar el tamaño de /tmp en Solaris y OpenIndiana

Introducción
En Solaris el directorio temporal </tmp>, o mejor dicho, el sistema de archivos <tmpfs> es un sistema de archivos en memoria, y por lo tanto, es muy eficiente, pero ... si no tenemos cuidado podemos tener problemas en nuestro host.

Por defecto, <tmpfs> utilizará nuestro área <swap> para crear la unidad, y por lo tanto, si no definimos unos valores máximos, podremos sufrir un desvanecimiento de nuestro host -por que se quede sin memoria física-.

Para solucionarlo, simplemente definiremos la opción <size=XYZm> en el archivo </etc/vfstab>, por ejemplo:
# cat /etc/vfstab |grep tmp
swap            -               /tmp            tmpfs   -       yes     -
# vi /etc/vfstab
  swap            -               /tmp            tmpfs   -       yes     size=512m
:wq
# cat /etc/vfstab |grep tmp
swap            -               /tmp            tmpfs   -       yes     size=512m

Referencias