SafeChildren Banner

Havoc Oracle Solaris Experts

viernes, 12 de noviembre de 2010

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

Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta última entrega vamos a ver el uso de <pfexec> -el sudo de Solaris- y cómo podemos aplicarlo en nuestro sistema

Que es <pfexec>
Podemos definir <pfexec> como una versión mejorada del comando <sudo>, el cual nos permite ejecutar comandos con unos privilegios diferentes a los que el usuario logeado tiene. Por ejemplo, podemos ejecutar un comando como si de <root> se tratase, o como otro.

<pfexec> nos permite asignar un grupo de propiedades como: uid, gid, euid, privileges, etc. De esta forma, podemos crear una forma sencilla de acceder a comando privilegiados por cuentas que no lo son.

La base de datos de <pfexec>
La definición de los comandos y sus opciones se encuentra en el archivo </etc/security/exec_attr> y su formato es el siguiente:
name:policy:type:res1:res2:id:attr
Donde
  • name, hace referencia al nombre de la política. Distingue entre mayúsculas y minúsculas
  • policy, hace referencia al tipo de política, puede tener los valores: suser o solaris. En versiones anteriores a Solaris 10, siempre era suser (Standar Solaris User), sin embargo, a partir de Solaris 10 se introdujo <solaris> que nos permite asignar <privileges>, cosa que con %lt;suser> no es posible. Además, <suser> es un subconjunto de <solaris>, por lo tanto, yo os recomiendo utilizar siempre <solaris> si utilizais la versión 10 o superior.
  •  type, hace referencia al tipo, donde puede tener los valores: act o cmd. El valor de <act> se utiliza cuando tenemos configurado <Trusted Extensions> y hace referencia a una acción de CDE. Si utilizamos el valor <cmd> hace referencia a un comando <shell>.
  • res1 y res2, están reservados para futuros usos
  • id, texto que identifica de forma única el objeto, es decir, si hemos definido <type> como <cmd>, entonces será el "full path" al comando. Podemos utilizar el "*" si queremos indicar "cualquier comando", por ejemplo, si queremos permitir la ejecución de todos los comandos de <sbin> del servidor de DHCP, pondremos <$DHCP_HOME/sbin/*>.
  • attr, son los atributos que quiero asignar a la política donde serán: euiduidegidgid, privs y limitprivs.
Por ejemplo, tenemos la siguiente entrada en la base de datos sobre el uso del comando <pfiles>
Process Management:solaris:cmd:::/usr/bin/pfiles:privs=proc_owner
Esta entrada, nos permitirá ejecutar el comando <pfiles> como utilizamos el <privilegio> >proc_owner> estaremos permitiendo enviar señales a otros procesos, a excepción de que tengan el uid=0.

Esto es un tema importante, es decir, si utilizamos el attr:uid=0, estaremos ejecutando el comando como <root>, sin embargo, al utilizar attr:privs=proc_owner, estamos diciendo que el comando se ejecuta con el uid del usuario, pero le concedemos el privilegio de enviar señales a los demás procesos siempre que no sean de <root&gt.  Esto lo explicaremos en el ejemplo, no os preocupeis.

Crear una nueva Política
El uso de <pfexec> está unido a las políticas, es decir, en la base de datos </etc/security/exec_attr> se encuentran "los detalles", sin embargo, la definición de una política se encuentra en </etc/security/prof_attr>, por lo tanto, para crear una nueva política deberemos definir primero la política en la base de datos </etc/security/prof_attr> y posteriormente añadir los comandos -o definición de la política- en la base de datos </etc/security/exec_attr>.

Por ejemplo, imaginemos que queremos crear una política nueva llamada <My Process Management> y queremos que esta política pueda ejecutar el comando </usr/bin/pfiles> con un <uid=0>, entonces haremos lo siguiente:

root@openzooey:/# echo "My Process Management:::Custom Process Management with UID to 0:help=RtProcessManage.html" >> /etc/security/prof_attr
root@openzooey:/# echo "My Process Management:solaris:cmd:::/usr/bin/pfiles:uid=0" >> /etc/security/exec_attr
De esta forma hemos creado una nueva política y hemos asignado unos atributos de ejecución.

Asignar una Política
La asignación de una política se realiza con el comando <rolemod> -si es un <role>- o &usermod> -si es un usuario- y la opción <-P '_policy_name1, _policy_name2, ...'>, por ejemplo:
root@openzooey:/# rolemod -P 'Process Management,Network Management' tomcat6
Podemos comprobar cómo se han añadido las nuevas políticas a nuestra base de datos de usuarios en </etc/user_attr>, por ejemplo,
root@openzooey:/# cat /etc/user_attr|grep tomcat6
tomcat6::::type=role;profiles=Process Management,Network Management
Eliminar una Política
Para eliminar una política, deberemos asignar una política vacía <-P ''>, es decir,
root@openzooey:/# rolemod -P '' tomcat6
root@openzooey:/# cat /etc/user_attr|grep tomcat6
tomcat6::::type=role

Ver los profiles asginados a un <role> o <user>
Para ver los profiles asignados utilizaremos el comando <profiles> y el nombre de usuario o role que queremos verificar, por ejemplo, si queremos ver los roles asignados al role <tomcat6> haremos lo siguiente:
root@openzooey:/# profiles tomcat6
tomcat6:
          Basic Solaris User
          All
Podemos utilizar el comando <-l> para ver de forma extendida la información, por ejemplo:

root@openzooey:/# profiles -l tomcat6
tomcat6:
      Basic Solaris User
          /usr/bin/cdda2wav.bin      privs=file_dac_read,sys_devices,proc_priocntl,net_privaddr
          /usr/bin/cdrecord.bin      privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr
          /usr/bin/readcd.bin        privs=file_dac_read,sys_devices,net_privaddr
      All
          *
Un Ejemplo Completo
Tenemos un <role> llamado <tomcat6> y queremos permitirle ver/modificar procesos del sistema. Para ello, hemos decidido añadirle la política <Process Management> que se encuentra ya definida en Solaris.

Esta política <Process Management> utiliza privilegios en vez de uid, por lo tanto, nos permitirá ver/modificar todos los procesos menos los que tengan uid=0 -es decir, de root-.

Lo primero que vamos a hacer es comprobar que <tomcat6> no tiene privilegios para modificar la prioridad del proceso <rcpbind> y luego asignaremos el <profile> "Process Management" para ver qué sucede:
root@openzooey:/# profiles tomcat6
tomcat6:
          Basic Solaris User
          All
root@openzooey:/# su - tomcat6
OpenIndiana     SunOS 5.11      oi_147  September 2010
tomcat6@openzooey:~$ ps -o pri,user,pid,nice,args -p 665
PRI     USER   PID NI COMMAND
 59   daemon   665  0 /usr/sbin/rpcbind
tomcat6@openzooey:~$ renice 10 665
renice: 665:setpriority: Not owner
Obviamente, Solaris no ha permitido a <tomcat6> modificar la prioridad del proceso porque no es su propietario, sin embargo, si asignamos el profile <Process Management>, veremos qué sucede,
root@openzooey:/# rolemod -P 'Process Management' tomcat6
root@openzooey:/# profiles tomcat6
tomcat6:
          Process Management
          Basic Solaris User
          All
root@openzooey:/# su - tomcat6
OpenIndiana     SunOS 5.11      oi_147  September 2010
tomcat6@openzooey:~$ ps -o pri,user,pid,nice,args -p 665
PRI     USER   PID NI COMMAND
 59   daemon   665  1 /usr/sbin/rpcbind
tomcat6@openzooey:~$ renice +19 665
tomcat6@openzooey:~$ ps -o pri,user,pid,nice,args -p 665
PRI     USER   PID NI COMMAND
 59   daemon   665 39 /usr/sbin/rpcbind
En esta ocasión hemos podido moficar el <nice> del proceso -aún cuando no es nuestro-, además este <profile> nos permite examinar los procesos aunque no sean nuestros -recordar lo que hemos hablado al principio sobre los privilegios priv=proc_owner-, vamos a verlo con detalle.

Ahora lo que vamos a utilizar el el comando <pfiles> para examinar los archivos abiertos de un proceso, para ello, vamos a examinar el proceso de <prostgres>
tomcat6@openzooey:~$ ps -o pri,user,pid,nice,args -p 614
PRI     USER   PID NI COMMAND
 59 postgres   614 20 /u01/app/postgres/9.0/db/bin/64/postgres -D /var/postgres/9.0/data
tomcat6@openzooey:~$ pfiles 614
614:    /u01/app/postgres/9.0/db/bin/64/postgres -D /var/postgres/9.0/data
  Current rlimit: 256 file descriptors
   0: S_IFCHR mode:0666 dev:524,0 ino:19922952 uid:0 gid:3 rdev:38,2
      O_RDONLY|O_LARGEFILE
      /devices/pseudo/mm@0:null
      offset:0
   1: S_IFREG mode:0600 dev:90,65538 ino:149346 uid:90 gid:90 size:156012
      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
      /var/log/postgres/server.log
      offset:156012
   2: S_IFREG mode:0600 dev:90,65538 ino:149346 uid:90 gid:90 size:156012
      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
      /var/log/postgres/server.log
      offset:156012
   3: S_IFDOOR mode:0444 dev:534,0 ino:47 uid:0 gid:0 size:0
      O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[462]
      /var/run/name_service_door
   7: S_IFSOCK mode:0666 dev:533,0 ino:45078 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK
        SOCK_DGRAM
        SO_DGRAM_ERRIND,SO_SNDBUF(57344),SO_RCVBUF(57344)
        sockname: AF_INET6 ::1  port: 59936
        peername: AF_INET6 ::1  port: 59936
Sin embargo, si ahora hacemos lo mismo sobre un proceso con uid=0, por ejemplo <nscd> veremos qué sucede
tomcat6@openzooey:~$ ps -ef|grep nscd|grep -v grep
    root   462     1   0 11:29:37 ?           0:09 /usr/sbin/nscd
tomcat6@openzooey:~$ pfiles 462
pfiles: permission denied: 462
Oops! Acceso denegado! Si, esto es debido al uso de privilegios y no <uid=0>. Esta es una gran diferencia con <sudo> ya que nos permite tener una definición mayor y más segura.

Cómo puedo hacer que se comporte como <sudo>
Bien, en nuestro ejemplo de Cómo crear una nueva política, hemos definido <My Process Management> donde permitíamos ejecutar el comando </usr/bin/pfiles> con el atributo <uid=0>, vamos a asignar este <profile> a nuestro usuario <tomcat6> y volveremos a comprobar su salida.

root@openzooey:/# rolemod -P 'My Process Management' tomcat6
root@openzooey:/# profiles -l tomcat6
tomcat6:
      My Process Management
          /usr/bin/pfiles            uid=0
      Basic Solaris User
          /usr/bin/cdda2wav.bin      privs=file_dac_read,sys_devices,proc_priocntl,net_privaddr
          /usr/bin/cdrecord.bin      privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr
          /usr/bin/readcd.bin        privs=file_dac_read,sys_devices,net_privaddr
      All
          *
root@openzooey:/# su - tomcat6
OpenIndiana     SunOS 5.11      oi_147  September 2010
tomcat6@openzooey:~$ ps -ef|grep nscd|grep -v grep
    root   462     1   0 11:29:37 ?           0:09 /usr/sbin/nscd
tomcat6@openzooey:~$ pfiles 462
462:    /usr/sbin/nscd
  Current rlimit: unlimited file descriptors
   0: S_IFCHR mode:0666 dev:524,0 ino:19922952 uid:0 gid:3 rdev:38,2
      O_RDWR
      /devices/pseudo/mm@0:null
      offset:0
   1: S_IFCHR mode:0666 dev:524,0 ino:19922952 uid:0 gid:3 rdev:38,2
      O_RDWR
      /devices/pseudo/mm@0:null
      offset:0
   2: S_IFCHR mode:0666 dev:524,0 ino:19922952 uid:0 gid:3 rdev:38,2
      O_RDWR
      /devices/pseudo/mm@0:null
      offset:0
   3: S_IFDOOR mode:0777 dev:527,0 ino:0 uid:0 gid:0 size:0
      O_RDWR FD_CLOEXEC  door to nscd[462]
   4: S_IFSOCK mode:0666 dev:533,0 ino:23670 uid:0 gid:0 size:0
      O_RDWR
        SOCK_RAW
        SO_SNDBUF(8192),SO_RCVBUF(8192)
        sockname: AF_ROUTE
        peername: AF_ROUTE
En esta ocasión sí que Solaris nos ha permitido ver los archivos abiertos de <nscd> porque hemos utilizado <uid=0> en los atributos, haciendo que se ejecute como <root>, por lo tanto, no hay limitaciones.

Cuando debo utilizar <pfexec _comando_> y cuando no
Lo cierto es que ya hemos hablado de esto en la entrega dedicada a los Roles en RBAC, Roles y Seguridas Parte 5 pero para hacer un breve resumen os diré
  • Hay que utilizar <pfexec _comando_> cuando queramos lanzarlo desde un <usuario>, ya que la <shell> de un usuario no es <pfXYZ>.
  • Si lanzamos el comando desde un <role>, no es necesario, ya tenemos asignada una <shell> &pfXYZ>, por lo tanto, no es necesario.

Conclusiones
Con esta entrega ya hemos cerrado el círculo de RBAC y Roles en Solaris, sólo nos queda la parte más importante, la auditoría que será el último artículo de esta serie.

Espero que con todo esto, ahora podáis utilizar las seguridades avanzadas que nos ofrece Solaris, y, sobre todo, pongáis en práctica todas aquellas modificaciones que se os ocurran.

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


Referencias

3 comentarios:

  1. Estimado muchas gracias por esta informacion me esta siendo muy util, por favor publica tu tutorial sobre auditoria que mencionas he escuchado hablar mucho de este concepto.

    Saludos desde Peru

    ResponderEliminar
  2. Hola Anónimo,

    Muchas gracias por tu comentario, y sí tengo que publicar el tema de la auditoría, ya que es muy importante, y muy útil.

    Estate atento, que pronto estará disponible :)

    Saludo a Perú desde España,
    Urko

    ResponderEliminar
  3. Hola Urko es posible hacer el que rol creado pueda cambiar contraseña.?

    bash-3.2$ profiles Operador
    Operator
    Printer Management
    Media Backup
    All
    Basic Solaris User
    bash-3.2$ passwd Operador
    Enter existing login password:
    Roles can only be assumed by authorized users
    Permission denied
    bash-3.2$

    ResponderEliminar