[ << ]
[ < ]
[ Inicio ]
[ > ]
[ >> ]
3. Órdenes en SELinux
Contenido:
3.a. Información sobre las órdenes en SELinux
Introducción
A estas alturas, debería tener un sistema con SELinux habilitado (pero
corriendo en modo permisivo (permissive) de modo que no obliga a cumplir
las reglas de la directriz). Por lo que antes de introducirle en el mundo
de SELinux y describir la forma de añadir más reglas sin perder la
funcionalidad cuando cambie al modo forzado (enforcing), echaremos un
vistazo rápido a algunas de las órdenes relacionadas con SELinux.
Comenzaremos con las órdenes de estado con las cuales puede obtener
información global sobre el estado de SELinux (si está corriendo
en modo forzado o no, conocer las versiones, etc).
Obteniendo el estado de SELinux
La primera orden de la que hablaremos es sestatus.
Listado de Código 1.1: Ejecutar sestatus |
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: strict
|
La salida de esta orden indica que SELinux está habilitado y está
trabajando actualmente en modo permisivo (permissive). También
nos indica que el sistema está configurado para correr en modo
estricto (strict) por lo que no existe el dominio unconfined_t.
La orden sestatus también ofrece una salida extendida si la
ejecuta con la opción -v option. Cuando se indica esta opción,
la orden devuelve los contextos de ficheros y procesos importantes:
Listado de Código 1.2: Correr sestatus -v |
# sestatus -v
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: strict
Process contexts:
Current context: staff_u:sysadm_r:sysadm_t
Init context: system_u:system_r:init_t
/sbin/agetty system_u:system_r:getty_t
/usr/sbin/sshd system_u:system_r:sshd_t
File contexts:
Controlling term: staff_u:object_r:user_devpts_t
/sbin/init system_u:object_r:init_exec_t
/sbin/agetty system_u:object_r:getty_exec_t
/bin/login system_u:object_r:login_exec_t
/sbin/rc system_u:object_r:rc_exec_t
/usr/sbin/sshd system_u:object_r:sshd_exec_t
/sbin/unix_chkpwd system_u:object_r:chkpwd_exec_t
/etc/passwd system_u:object_r:etc_t
/etc/shadow system_u:object_r:shadow_t
/bin/sh system_u:object_r:bin_t -> system_u:object_r:sh
ll_exec_t
/bin/bash system_u:object_r:shell_exec_t
/usr/bin/newrole system_u:object_r:newrole_exec_t
/lib/libc.so.6 system_u:object_r:lib_t -> system_u:object_r:li
b_t
/lib/ld-linux.so.2 system_u:object_r:lib_t -> system_u:object_r:ld
_so_t
|
Otra orden de estado general de SELinux es getenforce, el cual
le permite ver rápidamente si su SELinux está corriendo en modo
forzado (las directrices de SELinux se fuerzan), permisivo
(las directrices de SELinux policies se comprueban y registran pero no
se fuerzan) o deshabilitado (la directriz de SELinux no se carga y por
lo tanto no se comprueba).
Listado de Código 1.3: Usar la orden getenforce |
# getenforce
Enforcing
|
Obteniendo información de los objetos de SELinux
En la siguiente tabla se muestra la orden seinfo. Esta orden
le permite consultar la directriz en ejecución definida para todos los
objetos (tipos, roles, atributos, usuarios, booleanos,...).
Algunos usos comunes son los siguientes:
-
Comprobar si un dominio en particular se ha definido en su sistema
(para el caso en que se esté preguntando si necesita cargar algún
módulo adicional de directriz de SELinux o no).
-
Comprobar en qué dominios en particular puede estar un rol (para el
caso en que se esté preguntando si las directrices SELinux permiten
a sus usuarios normales cambiar a otro dominio).
-
Comprobar qué atributos están asignados a un dominio específico (o
viceversa, qué dominios tienen activado un atributo en particular) ya
que algunas reglas de directriz trabajan sobre atributos en lugar de
dominios.
Como ejemplo, consultaremos si se conoce el dominio crontab_t, si el rol
user_r puede usar el dominio contab_t y finalmente qué dominios tienen
el atributo cron_spool_type activado.
Listado de Código 1.4: Usar seinfo |
# seinfo -tcrontab_t
crontab_t
# seinfo -ruser_r -x
user_r
Dominated Roles:
user_r
Types:
[...]
crontab_t
[...]
# seinfo -acron_spool_type -x
cron_spool_type
user_cron_spool_t
system_cron_spool_t
|
Consultando las reglas de directriz de SELinux
Una orden que se usa menudo es sesearch. Esta orden le permite
consultar las reglas usadas en la directriz actual y es de gran ayuda
cuando queremos averiguar si algo está permitido (o porqué no
está permitido).
La orden sesearch se usa frecuentemente con un dominio origen
(-s), dominio destino (-t) o ambos, la clase sobre la que
quiere hacer la consulta permite reglas para: fichero, directorio, zócalo
(socket), proceso,... y el privilegio que quiere consultar: lectura,
escritura, transición, ejecución...
Por ejemplo, para averiguar qué dominios pueden escribir en los ficheros
que tienen el dominio shadow_t:
Listado de Código 1.5: Consultar las reglas de concesión con sesearch |
# sesearch -t shadow_t -c file -p write -A
Found 8 semantic av rules:
[...]
allow portage_t shadow_t : file { ioctl read write ... };
allow useradd_t shadow_t : file { ioctl read write ... };
...
|
Observará que en algunas ocasiones los resultados están basados en los
atributos en lugar de los dominios:
Listado de Código 1.6: Regla de permisión basada en atributo |
allow portage_t file_type : file { ioctl read write ... };
|
En este caso, al dominio origen (portage_t) se le permite escribir en
los ficheros cuyo dominio tengan el atributo file_type activado. Si ya le
va cogiendo el tacto a todo esto, se preguntará si la regla de arriba
no es un fallo flagrante en la seguridad ya que todos los dominios de los
ficheros tienen el atributo file_type activado. Sí y no, si echamos un
vistazo a los dominios que tienen privilegios para escribir en los
dominios file_type domains, se dará cuenta de que el único es portage:
Listado de Código 1.7: Consultar los dominios que tienen privilegios de escritura en fichero en dominios file_type |
# sesearch -t file_type -c file -p write -A -d
Found 1 semantic av rules:
allow portage_t file_type : file { ioctl read write ... };
|
Observe que tenemos una orden sin la opción -d y otra que usa
esta opción. Cuando se indica -d, la búsqueda será realizada de
forma exacta sin resolver los atributos. Cuando no se indica -d,
entonces se resolverá el atributo. En el último ejemplo, el hecho de no
indicar -d podría resultar en cientos de reglas de permisión: para
cada dominio que tenga file_type activado, la búsqueda intenta encontrar
reglas que permiten acceso de escritura al fichero en ese dominio en
particular.
Otra interesante funcionalidad de la orden sesearch es mostrarle
las reglas que se aplican dependiendo del estado de un booleano. Si quiere
consultar un booleano en particular, utilice -b. Si quiere ver la
lógica que usa la directriz, utilice, -C (y, sí, ambas opciones
se pueden combinar).
A modo de ejemplo, comprobaremos qué permitimos (o denegamos) cuando
el booleano global_ssp está habilitado.
Listado de Código 1.8: Comprobar la directriz respecto al booleano global_ssp |
# sesearch -b global_ssp -A -C -d
Found 2 semantic av rules:
ET allow domain device_t : dir { getattr search open } ; [ global_ssp ]
ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ]
|
El prefijo que se muestra al comienzo de las líneas consiste en dos letras,
las cuales están relacionadas con dos definiciones importantes:
-
¿Está la regla habilitada (Enabled) o deshabilitada
( Disabled)?
-
¿Necesita el booleano definirse a cierto (True) o falso
(or False para habilitar la regla?
Obteniendo información del contexto de seguridad
Mientras esté realizando labores de administración y especialmente cuando
esté comprobando si se está produciendo una denegación SELinux, es
importante averiguar qué contexto de seguridad se está empleando para un
recurso en particular. Afortunadamente, si se instala adecuadamente,
Gentoo Hardened ha modificado algunas herramientas para obtener esta
información usando sus herramientas estándar.
Para consultar el contexto de seguridad de un fichero, utilice ls -Z:
Listado de Código 1.9: Obtener el contexto de seguridad de un fichero |
~$ ls -Z /etc/make.conf
system_u:object_r:portage_conf_t /etc/make.conf
|
Para obtener el contexto de seguridad de un proceso, utilice ps -Z:
Listado de Código 1.10: Obtener el contexto de seguridad de un proceso |
# ps -Z $(pidof init)
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:00 init [3]
|
Para obtener el contexto de seguridad del usuario actual, utilice
id -Z:
Listado de Código 1.11: Obtener el contexto de seguridad de un usuario |
~$ id -Z
staff_u:staff_r:staff_t
|
3.b. Gestionar SELinux
Introducción
La gestión de los objetos de SELinux (booleanos, usuarios, puertos,
contextos ...) se realiza en la mayoría de las ocasiones usando
semanage. Debido a que esta aplicación ofrece la interfaz para
varias configuraciones de SELinux, le dedicaremos una sección completa,
aunque cubriremos también las órdenes que ofrecen una funcionalidad
parecida (y que en algunas ocasiones son más fáciles de recordar).
Booleanos
Hemos hablado de los booleanos de SELinux anteriormente en este libro
así como de las órdenes getsebool and setsebool. Con
semanage puede también gestionar los booleanos y, como valor
añadido, al listar los booleanos también se mostrará su descripción
(aunque queda aún trabajo por realizar en este área).
Listado de Código 2.1: Listar los booleanos de SELinux disponibles |
# semanage boolean -l
SELinux boolean Description
allow_ptrace -> off allow_ptrace
rsync_export_all_ro -> off rsync_export_all_ro
|
Nota:
Como habrá notado, la mayor parte de las descripciones consisten
únicamente en el nombre del booleano, sin embargo encontrará booleano
con una mejor descripción cuando se haya familiarizado y/o instale más
módulos de directriz de SELinux.
|
Puede definir el valor de un booleano con setsebool y
semanage:
Listado de Código 2.2: Definir el valor de un booleano de SELinux |
# semanage boolean -m --on -F user_dmesg
|
Usuarios y cuentas de SELinux
Los usuarios y cuentas de SELinux son diferentes de las de Unix. Las
cuentas de SELinux le permiten asociar una cuenta Unix a un usuario
SELinux:
Listado de Código 2.3: Listar las cuentas de SELinux |
# semanage login -l
Login Name SELinux User
__default__ user_u
root root
swift staff_u
system_u system_u
|
El comportamiento por defecto es que los usuarios ingresan en el sistema
como el usuario user_u de SELinux. Este usuario de SELinux es un
usuario no administrador: no tiene privilegios específicos y se debe
usar para para cada cuenta que nunca requiera elevar sus privilegios
(por lo que no tendrá privilegios su o sudo para nada).
La cuenta que use para administrar su sistema debe ser mapeada al
usuario SELinux staff_u (o su propio usuario con los roles
apropiados). Esto se puede conseguir de la siguiente forma (ejemplo
con la cuenta Unix ana):
Listado de Código 2.4: Permitir que 'ana' ingrese en el sistema como 'staff_u' |
# semanage login -a -s staff_u ana
|
Importante:
Asegúrese de que sea cual sea la cuenta que utilice para administrar
su sistema, está mapeada al usuario staff_u o tiene la capacidad
de cambiar al rol sysadm_r. Portage únicamente trabaja desde el
rol sysadm_r.
|
Como se ha mencionado, los usuarios SELinux están configurados para que
puedan unirse a uno o más roles. Para listar los roles disponibles, puede
usar semanage user -l:
Listado de Código 2.5: Listar las asociaciones de cuentas a roles |
# semanage user -l
SELinux User SELinux Roles
root staff_r sysadm_r
staff_u staff_r sysadm_r
[...]
|
Gestionando puertos
Incluso los puertos (como el puerto 22 para SSH) están 'protegidos' por
SELinux. Para echar un vistazo rápido de qué dominios están asignados
a qué puertos (o rangos de puertos) utilice semanage port -l.
Listado de Código 2.6: Listar los puestos gestionados por SELinux |
# semanage port -l | grep '22$'
ssh_port_t tcp 22
|
3.c. Usar SELinux
Introducción
Hasta ahora hemos visto cómo obtener información relacionada con SELinux
así como la gestión de los ajustes de SELinux. Sin embargo los usuarios
de un sistema reforzado con SELinux necesitarán también saber algunas
cosas acerca de cómo trabajar con SELinux, incluyendo (pero no
limitándose a) roles y transiciones entre roles.
Cambiando de roles
Como una forma más del reforzamiento de un sistema de control de acceso,
SELinux permite que algunos roles en particular estén en un conjunto de
dominios. Si está utilizando un rol que no está permitido en un dominio
en particular, no podrá usar ese dominio y se le denegará el acceso a las
acciones asignadas a ese dominio.
Si sus usuarios estándar son todos usuarios user_u de SELinux
(soportándose únicamente el rol user_r), entonces estos usuarios nunca
necesitarán cambiar a otro rol (aunque tampoco se les permitiría). Sin
embargo, se tiene que dejar bien claro como cambian entre roles los
usuarios que son staff_u (u otros usuarios que tienen múltiples roles).
Hemos visto cómo asociar estos usuarios al usuario correcto SELinux
(mire Usuarios y cuentas de SELinux).
La orden que permite cambiar entre roles es newrole. Su uso es
bastante lógico.
Listado de Código 3.1: Usar newrole |
~$ newrole -r sysadm_r
Password:
|
Cuando se realiza una transición de rol, SELinux pedirá que el usuario
vuelva a autenticarse usando su contraseña.
[ << ]
[ < ]
[ Inicio ]
[ > ]
[ >> ]
El contenido de este documento, a no ser que se especifique
expresamente, está registrado bajo los términos de la licencia
CC-BY-SA-2.5. Se aplican las
Pautas de
Utilización del logotipo y nombre de Gentoo.
|