newrole -r rol_r -t dominio_t
(habitualmente se permite un único dominio para un rol determinado por lo que puede omitir el parámetro -t
). Este programa lo autenticará pidiéndole que ingrese su contraseña. Esta característica impide que los programas cambien de rol de forma automática. Estos cambios sólo pueden ocurrir si se permiten explícitamente en la política de seguridad de SELinux.
ssh
con ssh_exec_t
y, cuando inicia el programa, automáticamente cambia al dominio ssh_t
). Este mecanismo de transición automática de dominios permite otorgar exclusivamente los permisos que requiere cada programa. Es un principio fundamental de SELinux.
apt install selinux-basics selinux-policy-default
command will automatically install the packages required to configure an SELinux system.
unconfined
(detallamos la gestión de módulos más adelante en esta sección).
fixfiles relabel
.
selinux=1 security=selinux
parameter to the Linux kernel. The audit=1
parameter enables SELinux logging which records all the denied operations. Finally, the enforcing=1
parameter brings the rules into application: without it SELinux works in its default permissive mode where denied actions are logged but still executed. You should thus modify the GRUB bootloader configuration file to append the desired parameters. One easy way to do this is to modify the GRUB_CMDLINE_LINUX
variable in /etc/default/grub
and to run update-grub
. SELinux will be active after a reboot.
selinux-activate
automatiza todas estas operaciones y fuerza el etiquetado de archivos en el siguiente reinicio (lo que evita que se creen nuevos archivos sin etiquetar cuando SELinux aún no esta activo mientras se realiza el etiquetado).
semodule
. Lo que es más, debería tener la capacidad de definir los roles que cada usuario puede adoptar, lo que puede realizar con el programa semanage
.
/etc/selinux/default/
. A diferencia de otros archivos de configuración que puede encontrar en /etc/
, no debe modificar estos archivos manualmente. Debe utilizar los programas diseñados para este propósito.
/usr/share/selinux/default/
directory. To enable one of these modules in the current configuration, you should use semodule -i module.pp.bz2
. The pp.bz2 extension stands for policy package (compressed with bzip2).
semodule -r module
. Finally, the semodule -l
command lists the modules which are currently installed. It also outputs their version numbers. Modules can be selectively enabled with semodule -e
and disabled with semodule -d
.
#
semodule -i /usr/share/selinux/default/abrt.pp.bz2
#
semodule -l
abrt 1.5.0 Disabled accountsd 1.1.0 acct 1.6.0 [...]
#
semodule -e abrt
#
semodule -d accountsd
#
semodule -l
abrt 1.5.0 accountsd 1.1.0 Disabled acct 1.6.0 [...]
#
semodule -r abrt
#
semodule -l
accountsd 1.1.0 Disabled acct 1.6.0 [...]
semodule
carga inmediatamente la nueva configuración a menos que utilice la opción -n
. De forma predeterminada, el programa actúa sobre la configuración actual (indicada por la variable SELINUXTYPE
en el archivo /etc/selinux/config
), pero también puede modificar una distinta especificándola con la opción -s
.
semanage
.
-a
para agregar, -d
para borrar, -m
para modificar, -l
para enumerar y -t
para indicar un tipo (o dominio).
semanage login -l
enumera las correspondencias actuales entre identificadores de usuarios y entidades SELinux. Los usuarios que no aparecen explícitamente poseen la identidad predeterminada, que corresponde al elemento __default__
. Si ejecuta semanage login -a -s user_u usuario
, asociará la identidad user_u con el usuario dado. Por último, semanage login -d usuario
elimina la asociación asignada al usuario.
#
semanage login -a -s user_u rhertzog
#
semanage login -l
Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u SystemLow-SystemHigh * rhertzog user_u SystemLow * root unconfined_u SystemLow-SystemHigh * system_u system_u SystemLow-SystemHigh * #
semanage login -d rhertzog
semanage user -l
enumera las asociaciones entre las identidades de usuario de SELinux y los roles permitidos. Agregar una nueva identidad requiere definir tanto sus roles correspondientes como un prefijo de etiquetado que se utiliza para asignar un tipo a los archivos personales (/home/usuario/*
). Debe elegir el prefijo entre user
, staff
y sysadm
. El prefijo «staff
» hace que los archivos sean del tipo «staff_home_dir_t
». Para crear una nueva identidad de usuario SELinux, ejecute semanage user -a -R roles -P prefijo identidad
. Puede eliminar una identidad de usuario SELinux ejecutando semanage user -d identidad
.
#
semanage user -a -R 'staff_r user_r' -P staff test_u
#
semanage user -l
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm SystemLow SystemLow-SystemHigh staff_r sysadm_r system_r staff_u staff SystemLow SystemLow-SystemHigh staff_r sysadm_r sysadm_u sysadm SystemLow SystemLow-SystemHigh sysadm_r system_u user SystemLow SystemLow-SystemHigh system_r test_u staff SystemLow SystemLow staff_r user_r unconfined_u unconfined SystemLow SystemLow-SystemHigh system_r unconfined_r user_u user SystemLow SystemLow user_r #
semanage user -d test_u
/srv/www/
, podría ejecutar semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
seguido de restorecon -R /srv/www/
. La primera ejecución registra las nuevas reglas de etiquetado, mientras que la segunda hace que se reinicialicen los tipos de archivo según las reglas de etiquetado actuales.
semanage port -m -t http_port_t -p tcp 8080
.
getsebool
para inspeccionar estas opciones (getsebool opcion_booleana
muestra una opción concreta, mientras que getsebool -a
muestra todas). La orden setsebool opción_booleana valor
cambia el valor de una opción booleana. La opción -P
hace que el cambio sea permanente, es decir que el nuevo valor se convierte en el predeterminado y se mantiene después de reiniciar el equipo. El ejemplo a continuación permite a los servidores web acceso a los directorios personales (esto es útil cuando los usuarios tienen sitios web personales en ~/public_html/
).
#
getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off #
setsebool -P httpd_enable_homedirs on
#
getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on
/usr/share/doc/selinux-policy-doc/html/
) y los archivos de ejemplo que puede utilizar como plantillas para crear nuevo módulos. Instale estos módulos y estúdielos detenidamente:
$
cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile
$
cp /usr/share/doc/selinux-policy-doc/example.fc ./
$
cp /usr/share/doc/selinux-policy-doc/example.if ./
$
cp /usr/share/doc/selinux-policy-doc/example.te ./
.te
file is the most important one. It defines the rules. The .fc
file defines the “file contexts”, that is the types assigned to files related to this module. The data within the .fc
file are used during the file labeling step. Finally, the .if
file defines the interface of the module: it is a set of “public functions” that other modules can use to properly interact with the module that you're creating.
myapp_domtrans
») controla quién puede utilizar la aplicación. La segunda («myapp_read_log
») otorga permisos de escritura a los archivos de registro de la aplicación.
.te
. Por lo tanto, debe declarar todos los tipos que utilizará (con el macro gen_require
) y utilizar directivas estándar para otorgar permisos. Sepa que puede utilizar interfaces proporcionadas por otros módulos. La siguiente sección dará más explicaciones sobre cómo expresar estos permisos.
Ejemplo 14.3. Archivo ejemplo.if
## <summary>Política de ejemplo de Myapp</summary> ## <desc> ## <p> ## Texto más descriptivo de myapp. La etiqueta <desc> ## también puede utilizar etiquetas HTML <p>, ## <ul>, and <ol> para dar formato. ## </p> ## <p> ## Esta política es compatible con las siguientes ## funcionalidades de myapp: ## <ul> ## <li>Funcionalidad A</li> ## <li>Funcionalidad B</li> ## <li>Funcionalidad C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Ejecutar una transición de dominio para ejecutar myapp. ## </summary> ## <param name="domain"> ## Dominio permitido para la transición ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Leer archivos de registro de myapp. ## </summary> ## <param name="domain"> ## Dominio al que se le permite leer archivos de registro. ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file r_file_perms; ')
example.te
:
policy_module(myapp,1.0.0)######################################## # # Declaraciones # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Política local de Myapp # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
El módulo debe ser identificado por su nombre y número de versión. Esta directiva es obligatoria.
| |
Si el módulo introduce tipos nuevos, debe declararlos con directivas como las siguientes. No dude en crear tantos tipos como necesite en lugar de otorgar demasiados permisos inútiles.
| |
Dichas interfaces definen el tipo myapp_t como un dominio de proceso que cualquier ejecutable con la etiqueta myapp_exec_t debería utilizar. Implícitamente, esto agrega un atributo exec_type en estos objetos, lo que a su vez permite a otros módulos otorgar permisos para ejecutar dichos programas: por ejemplo, el módulo userdomain permite que los ejecuten los proceso con dominios user_t , staff_t y sysadm_t . Los dominios de otras aplicaciones confinadas no tendrán los permisos para ejecutarlos a menos que las reglas les otorguen permisos similares (este es el caso, por ejemplo, de dpkg con su dominio dpkg_t ).
| |
logging_log_file es una interfaz provista por la política de referencia. Indica que los archivos etiquetados con el tipo dado son archivos de registro que deben gozar de los beneficios de las reglas asociadas (por ejemplo, otorgando permisos a logrotate para que los pueda manipular).
| |
La directiva allow es la directiva base para autorizar una operación. El primer parámetro es el dominio de proceso al que se le permite ejecutar la operación. El segundo define el objeto que puede manipular un proceso del dominio anterior. Este parámetro debe estar en el formato «tipo:clase», en el que tipo es el tipo SELinux y clase describe la naturaleza del objeto (archivo, directorio, zócalo, tubería, etc.). Finalmente, el último parámetro describe los permisos (las operaciones permitidas).
Permissions are defined as the set of allowed operations and follow this template: { operation1 operation2 } . However, you can also use macros representing the most useful permissions. The /usr/share/selinux/devel/include/support/obj_perm_sets.spt lists them.
La siguiente página web provee una lista relativamente exhaustiva de las clases de objetos y los permisos que puede otorgar.
|
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1
Tabla 14.1. Análisis de una traza SELinux
Mensaje | Descripción |
---|---|
avc: denied | Se denegó una operación. |
{ read write } | Esta operación necesita los permisos read y write . |
pid=1876 | El proceso con PID 1876 ejecutó la operación (o intentó hacerlo). |
comm="syslogd" | Este proceso era una instancia del programa syslogd . |
name="xconsole" | The target object was named xconsole . Sometimes you can also have a “path” variable — with the full path — instead. |
dev=tmpfs | The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example: “sda3”). |
ino=5510 | El objeto está identificado por el número de inodo 5510. |
scontext=system_u:system_r:syslogd_t:s0 | Este es el contexto de seguridad del proceso que ejecutó la operación. |
tcontext=system_u:object_r:device_t:s0 | Este es el contexto de seguridad del objeto destino. |
tclass=fifo_file | El objeto destino es un archivo FIFO. |
allow syslogd_t device_t:fifo_file { read write }
. Se puede automatizar este proceso, que es exactamente lo que ofrece el paquete audit2allow
(del paquete policycoreutils. Este enfoque sólo es útil si ya están etiquetados correctamente los muchos objetos que deben ser confinados. En cualquier caso, debe revisar cuidadosamente las reglas generadas y validarlas según su conocimiento de la aplicación. En efecto, este enfoque tiende a otorgar más permisos de los que son realmente necesarios. La solución apropiada generalmente es crear nuevos tipos y otorgar los permisos sólo sobre dichos tipos. También puede suceder que denegar una operación no es fatal para la aplicación, en cuyo caso podría ser mejor simplemente agregar una regla «dontaudit
» para evitar que sea registrada a pesar de que sea denegada.
example.if
, example.fc
, and example.te
) match your expectations for the new rules, just run make NAME=devel
to generate a module in the example.pp
file (you can immediately load it with semodule -i example.pp
). If several modules are defined, make
will create all the corresponding .pp
files.