Configuración fedora
/etc/sysconfig/selinux
Estado
# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 29
SELinux status: enabled
Modos
enforcing: Fuerza la aplicación de la politica SE. Deniega acceso y loguea las operaciones.
permissive: No deniega acceso, solo emite avisos. Se usa para depurar problemas con SE.
disabled: SELinux deshabilitado.
Politicas
SELinux permite varias políticas diseñadas para ser intercambiables.
Se puede ver las instaladas con:
# rpm -qa | grep selinux-policy
selinux-policy-3.13.1-105.9.fc21.noarch
selinux-policy-targeted-3.13.1-105.9.fc21.noarch
Estan instaladas en /etc/selinux//
.
En Fedora la política por defecto es
targeted.
En esta política todo corre sobre el dominio unconfined_t, excepto para ciertos demonios específicos. Los objetos en unconfined_t no tienen restricciones y equivalen a los accesos de Unix estandar (DAC).
Herramientas para modificar la política
audit2allow
Permite modificar reglas de la política basado en el log de auditoría.
Documentacion audit2allow en CentOS 5
Booleans
Permiten modificar el comportamiento de la política sin necesidad de recompilar la misma.
Documentacion Booleans en CentOS 5
Control de acceso
SELinux tiene tres modos de acceso:
Type Enforcement (TE): Es el mecanismo primario usado en la targeted
Role-Based Access Control (RBAC): Basado en usuarios SELinux que no necesariamente coinciden con los usuarios del sistema no se usa en la politica targeted
Multi-Level Security (MLS): No usada habitualmente y oculta a veces en la politica targeted.
De los procesos y ficheros se pueden ver con los comandos habituales y la opción (-Z) los campos del contexto de seguridad:
Ver procesos:
# ps -eZ | grep httpd
system_u:system_r:httpd_t:s0 889 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 1255 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 1256 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 1257 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 1258 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 1259 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 3126 ? 00:00:00 httpd
system_u:system_r:httpd_t:s0 3811 ? 00:00:00 httpd
# ps -eZ | grep bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2826 pts/0 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3626 pts/0 00:00:01 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 7524 pts/1 00:00:00 bash
Ver ficheros:
# ls -Z /etc/passwd
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd
Estos campos estan basados en user:role:type:mls, en los ejemplos el campo mls esta oculto. En la politica
targeted el campo mas importante es el
type.
El acceso solo esta permitido entre tipos similares.
Modificacion de contexto de seguridad
Añadimos el directorio R_Tutorial a nuestro arbol del servidor http, pero este no tiene acceso, revisamos los permisos y vemos que el campo type no es correcto:
www # ls -Z
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 ProGit2.0
drwxrwxr-x. root root unconfined_u:object_r:user_home_t:s0 R_Tutorial
Cambiamos el contexto:
chcon -Rv --type=httpd_sys_content_t R_Tutorial/
Verificamos que ya accedemos correctamente:
www # ls -Z
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 ProGit2.0
drwxrwxr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 R_Tutorial
