PDF de programación - Practica SELinux

Practica SELinux

SELinux: Teoria
Por Javier Vela, 11 de Mayo de 2010 |



Lo prometido es deuda, y hoy vamos a explicar un poco que es SELinux [Security-
Enhanced Linux, enlace de la NSA] y cómo opera. Recomiendo releer la entrada sobre
MAC y DAC para recordar conceptos. Tras esto, ¿qué es SELinux? SELinux es una
implementacion del MAC que funciona a nivel de kernel, lo que implica que las
aplicaciones no necesitan ser modificadas para aprovechar toda su potencia, ya que para
ellas SELinux es transparente, algo muy importante a la hora de que el sistema sea
desplegado en un entorno real.

La razón de usar SELinux es limitar el acceso que tienen las aplicaciones a otras
aplicaciones y a los ficheros, impidiendo que un proceso pueda modificar cualquier fichero
del usuario con el que se lanzó. Por ejemplo, Firefox jamas debería ser capaz de cambiar
los permisos de mi clave privada ssh, lo cual con un sistema de control de acceso DAC sí
sería posible si un atacante toma el control del navegador.

¿Cómo funciona SELinux? Pues se basa en atributos extendidos del sistema de ficheros que
indican el tipo de usuario (que no tiene porque ser usuario del sistema), el rol, y el tipo del
objeto. Por ejemplo, si hacemos un ls -lZ para ver los atributos extendidos del directorio
/etc/httpd, podremos ver que permisos le asigna una distribución Red Hat a los ficheros de
configuración de Apache (la quinta línea se ha partido para facilitar su presentación):

[root@localhost httpd]# ls -lZ
drwxr-xr-x root root system_u:object_r:httpd_config_t conf
drwxr-xr-x root root system_u:object_r:httpd_config_t conf.d
lrwxrwxrwx root root system_u:object_r:httpd_log_t logs ->
../../var/log/httpd
lrwxrwxrwx root root system_u:object_r:httpd_modules_t modules ->
../../usr/lib/httpd/modules
lrwxrwxrwx root root system_u:object_r:httpd_config_t run ->
../../var/run

Como podemos ver, el usuario y rol es el mismo, pero el tipo cambia. Estos atributos son
los que en función de las políticas definidas en SELinux, indican las interacciones entre
ellos y los diferentes objetos del sistema. Estos atributos están definidos en el sistema, y
puede haber cientos, tantos como la granularidad que queramos obtener. La mayoría de
distribuciones que usan SELinux vienen ya con varios tipos predeterminados para
ayudarnos en su administración, pero nosotros podemos definir más. Si queremos ver todos
los tipos disponibles, lo podemos hacer con el comando

#getsebool -a

Ahora que ya conocemos los atributos, ahora nos falta conocer un poco las políticas que
utilizan estos atributos. Al más alto nivel, existen dos tipos de políticas básicas: targeted y
strict:

•

•

strict: En modo estricto, por defecto todo está denegado, y tan sólo se permite lo
especificado en la políticas. Esto, que sigue el principio de mínimo privilegio, es
complicado de administrar y llevaría a la mayoría de los sysadmins a desactivar
SELinux.
targeted: Tan sólo ciertos servicios están bajo la supervisión de SELinux, como por
ejemplo los demonios httpd, bind, postgresql, etc. El resto están libres de
restricciones. La denominacion Targeted proviene del hecho de que tan solo los
servicios señalados serán vigilados.

Para saber qué tipo de política tenemos configurada, en un sistema Red Hat podemos
averiguarlo en el fichero /etc/sysconfig/selinux.

Por debajo de estos modos, se sitúan las políticas en sí, que definen las interacciones entre
objetos. Dichas políticas pueden usar diferentes controles de acceso, en función de los
atributos extra que utilicen. Normalmente se suele usar Type Enforcement en el cual tan
solo se utiliza el atributo tipo, y es el modo usado por la política targeted. Existen otros
métodos como el Role-Based Access Control que utiliza los atributos de usuario y rol pero
normalmente, dado que como política se utiliza targeted, el modo de acceso mas común es
el Type Enforcement.

Ya tan sólo nos queda saber qué es lo que exactamente permite o impide que podamos
acceder a un objeto. Aquí entran en juego las políticas, que dependiendo del control de
acceso utilizado y los atributos de los objetos, permiten o deniegan un acceso. Así pues, si
usamos el modo de Type Enforcement, es el tipo de un objecto el atributo determinante. En
este caso, si un servicio esta en el modo vigilado tan solo podrá acceder a objetos con un
tipo similar. En las políticas se definen los tipos similares y las excepciones que permiten
que el sistema funcione. Así, por ejemplo, si inspeccionamos con que permisos se ejecuta el
demonio Apache (la segunda línea se ha partido para facilitar su presentación):

[root@localhost etc]# ps auxZ | grep httpd
user_u:system_r:httpd_t root 2869 0.3 0.5 10548 2924 ? Ss 15:46 0:00
/usr/sbin/httpd

Vemos que dicho demonio tan solo podrá interactuar con objetos de un tipo similar, como
por ejemplo los que están en el directorio /etc/httpd. Esto implica que aunque nosotros
tuviéramos un fichero con permisos de lectura y escritura para todos, como por ejemplo:

[root@localhost jvela]# ls -lZ /home/jvela
drwxr-xrwx jvela jvela user_u:object_r:user_home_t prueba_selinux

Un atacante que comprometiera el demonio de httpd no podría acceder porque dicho
demonio esta en el dominio de SELinux y el tipo de nuestro archivo no pertenece a la
“familia” httpd.

Hemos visto por encima que es SElinux, cómo esta estructurado y como consigue aplicar el
MAC a un sistema GNU\Linux. Por supuesto, como pasa siempre, la mejor manera de
comprender su funcionamiento es jugando con él y poniéndolo en marcha, algo a lo que les

invito. No obstante, si les queda alguna duda o hay algo de lo dicho sobre lo que les
gustaría que incidiese, no tienen más que indicarlo en los comentarios y estaré encantado de
aclarar las dudas que tengan. En la siguiente entrada pasaremos de la teoría a la práctica,
con ejemplos de su funcionamiento y las múltiples opciones de configuración que lo
convierten en un sistema tan flexible.



SELinux II: Práctica
Por Javier Vela, 16 de Junio de 2010 |



Bueno, lo prometido es deuda, y aunque debería de pagar intereses por el tiempo
transcurrido, vamos a pasar de la teoría de SElinux a la práctica.

Lo primero antes de trabajar con SElinux, es asegurarse de que lo tenemos habilitado, de
que esta configurado en el modo adecuado y de la política de que tenemos. Para todo ello,
en un sistema Red Hat, inspeccionamos el fichero /etc/sysconfig/selinux

jvela@centos:~$ less /etc/sysconfig/selinux
SELINUX=enforcing
SELINUXTYPE=targeted

Lo primero que deberemos aprender es cómo configurar los servicios que están bajo la
protección de selinux. Para ello, man es nuestro amigo y consejero. Si ejecutamos man
selinux, aparte de bastante información, veremos al final cuales son los ficheros de ayuda
de selinux para los diferentes servicios del sistema.

jvela@centos:~$ man selinux

(...)

SEE ALSO
booleans(8), setsebool(8), selinuxenabled(8), togglesebool(8),
restorecon(8), setfiles(8), ftpd_selinux(8), named_selinux(8),
rsync_selinux(8), httpd_selinux(8), nfs_selinux(8),
samba_selinux(8),
kerberos_selinux(8), nis_selinux(8), ypbind_selinux(8)

En este momento ya podemos intuir que si queremos configurar, por ejemplo, el vstftpd
deberemos consultar la ayuda ftpd_selinux. Como ejemplo, si quisiéramos configurar vsftp
para que los usuarios anónimos puedan leer y escribir en el directorio /var/ftp la propia
ayuda nos indica los pasos a realizar. En nuestro caso, deberemos asignar correctamente el
contexto del directorio y habilitar las políticas que permiten a los usuarios anónimos
escribir:

# Asignamos el tipo adecuado al directorio
root@centos:~# chcon -R -t public_content_rw_t /var/ftp

# Habilitamos la opcion de escritura para usuarios anónimos
root@centos:~# setsebool -P allow_ftpd_anon_write on

Cuando ejecutemos las pruebas, setroubleshoot nos avisará en tiempo real de cualquier
denegación por parte de Selinux, y nos mostrara una pantalla gráfica (gracias a sealert) de
los problemas que vayan ocurriendo, por qué han ocurrido y si sabe, cómo solucionarlos.

Hasta aquí, con la ayuda de las paginas man, el comando setsebool para definir los
booleanos y el comando chcon para cambiar el tipo podemos ajustar totalmente la
configuración básica de Selinux. ¿Y si queremos realizar alguna tarea que no esta prevista
en las políticas que trae por defecto Selinux y ningún booleano nos permite cambiar su
funcionamiento? ¿Debemos comenzar a escribir nuestras propias políticas y comenzar a
investigar en las tripas de Selinux? Por suerte para nosotros no es así, ya que existen
herramientas que automatizan dicho proceso.

Para ilustrar el ejemplo, vamos a realizar una pagina web muy simple en PHP que accede a
la clave privada ssh de un usuario. Con este ejemplo mataremos dos pájaros de un tiro:
veremos como SElinux nos protege incluso aunque hayamos cometido un error al dar
permisos a otros usuarios del sistema a nuestra clave privada, y podremos configurar
SElinux para que finalmente permita realizar esta acción (la razón la eligen ustedes, porque
a mí no se me ocurre ninguna para que un script ejecutado en un servidor web escriba en mi
clave privada.)

Pongámonos en antecedentes: tenemos una clave el directorio /home/javi/.ssh/ con unos
permisos erróneos, porque somos unos manazas con el comando chmod y el tipo SElinux
home_ssh

javi@centos:~/.ssh/ls -lZ
rw-rw-rw-. javi javi user_u:object_r:home_ssh_t:s0 prueba_selinux

También tenemos un script en PHP que accede a dicha clave:

<html>
<head>
<title>Selinux Test</title>
</head>
<body>
< ?php
$fp = fopen('/home/javi/.ssh/prueba_selinux', 'w');
fwrite($fp, 'One ring to rule...');
fclose($fp);
?>
</body>
</html>

Dicho script se ejecuta en un Apache con el siguiente contexto SElinux:

root@centos:~# ps auxZ | gr