* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened/selinux: hb-appendix-reference.xml hb-appendix-troubleshoot.xml hb-intro-concepts.xml hb-intro-enhancingsecurity.xml hb-intro-referencepolicy.xml hb-using-commands.xml hb-using-enforcing.xml hb-using-install.xml hb-using-permissive.xml hb-using-policymodules.xml selinux-handbook.xml
@ 2011-06-07 18:05 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; only message in thread
From: JosA MarAa Alonso (nimiux) @ 2011-06-07 18:05 UTC (permalink / raw
To: gentoo-commits
nimiux 11/06/07 18:05:53
Added: hb-appendix-reference.xml
hb-appendix-troubleshoot.xml hb-intro-concepts.xml
hb-intro-enhancingsecurity.xml
hb-intro-referencepolicy.xml hb-using-commands.xml
hb-using-enforcing.xml hb-using-install.xml
hb-using-permissive.xml hb-using-policymodules.xml
selinux-handbook.xml
Log:
Spanish translation of SELinux handbook
Revision Changes Path
1.1 xml/htdocs/proj/es/hardened/selinux/hb-appendix-reference.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-appendix-reference.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-appendix-reference.xml?rev=1.1&content-type=text/plain
Index: hb-appendix-reference.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-appendix-reference.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>1.3</version>
<date>2011-01-07</date>
<section>
<title>Conceptos previos</title>
<subsection>
<title>Introducción a SELinux</title>
<body>
<ul>
<li>
<uri
link="http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml">
Lo inevitable del fallo: La presunción errónea de la seguridad en los
entornos de computación modernos</uri> explica la necesidad de los
controles de acceso obligatorio.
</li>
<li>
<uri
link="http://www.nsa.gov/research/_files/selinux/papers/flask-abs.shtml">
La arquitectura de seguridad Flask: Un sistema de soporte para diversas
directrices de seguridad</uri> explica la arquitectura de seguridad
de Flask, que es la usada por SELinux.
</li>
<li>
<uri
link="http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml">
Implementando SELinux como un módulo de seguridad</uri> ofrece detalles
específicos sobre las comprobaciones de acceso SELinux en el núcleo.
</li>
</ul>
</body>
</subsection>
</section>
<section>
<title>Directriz de SELinux</title>
<subsection>
<title>Referencias relacionadas con la directriz</title>
<body>
<ul>
<li>
<uri
link="http://www.nsa.gov/research/_files/selinux/papers/policy2-abs.shtml">
Configurar la directriz de SELinux</uri>
</li>
<li>
<uri link="http://oss.tresys.com/projects/refpolicy">Referencia de la
directriz de SELinux</uri>
</li>
<li>
Vista rápida de los <uri
link="http://www.selinuxproject.org/page/ObjectClassesPerms">permisos y
clases de objetos</uri>
</li>
</ul>
</body>
</subsection>
</section>
<section>
<title>Libros</title>
<subsection>
<title>Libros en papel</title>
<body>
<ul>
<li>
<c>SELinux mediante ejemplos: Usando la seguridad mejorada de SELinux</c>,
por Frank Mayer, Karl MacMillan y David Caplan. Prentice Hall, 2006;
ISBN 0131963694
</li>
<li>
<c>SELinux: Linux con la seguridad mejorada de código abierto de NSA</c>,
por Bill McCarty. O'Reilly Media, 2004; ISBN 0596007167
</li>
</ul>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-appendix-troubleshoot.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-appendix-troubleshoot.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-appendix-troubleshoot.xml?rev=1.1&content-type=text/plain
Index: hb-appendix-troubleshoot.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-appendix-troubleshoot.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>0</version>
<date>2011-02-24</date>
<section>
<title>No se puede cargar la directriz de SELinux</title>
<subsection>
<title>Descripción del problema</title>
<body>
<p>
Si observa que SELinux no está funcionando, puede ejecutar
<c>sestatus</c> para ser informado rápidamente si SELinux está
habilitado y cargado o no. Si obtiene la siguiente salida, entonces
ninguna directriz de SELinux se ha cargado:
</p>
<pre caption="Salida de sestatus">
SELinux status: disabled
</pre>
<p>
Si éste es el caso, continúe leyendo esta sección para averiguar cómo
corregir esta situación.
</p>
</body>
</subsection>
<subsection>
<title>No hay ninguna directriz instalada</title>
<body>
<p>
Una raíz potencial de este problema es que no hay ninguna directriz con
la que comenzar. Eche un vistazo a <path>/usr/share/selinux/strict</path>
o a <path>/usr/share/selinux/targeted</path> (dependiendo de su
configuración) y busque un fichero llamado <path>base.pp</path>. Si no
existe este fichero, necesitará instalar la directriz base. Esta
directriz se ofrece con el paquete
<path>sec-policy/selinux-base-policy</path>, pero es mejor leer el
capítulo relacionado con la <uri link="?part=2&chap=1">Instalación de
Gentoo SELinux / Conversión</uri> ya que podría pasar por alto detalles
importantes.
</p>
</body>
</subsection>
<subsection>
<title>La directriz no se ha cargado</title>
<body>
<p>
Si existe el fichero <path>base.pp</path> en
<path>/usr/share/selinux/strict</path> (o en <path>targeted/</path>),
eche un vistazo a <path>/etc/selinux/strict/policy</path>. Esta
localización también debería contener un módulo de directriz
<path>base.pp</path> (cuando se carga una directriz de SELinux, se
copia desde la primera localización a la segunda).
</p>
<p>
Si no existe el fichero <path>base.pp</path>, instale la directriz y
cárguela:
</p>
<pre caption="Instalar la directriz base">
~# <i>semodule -n -B</i>
</pre>
<p>
Esto es una operación que se realiza solo en una ocasión. Una vez
instalada y cargada, ésta será recargada en cada reinicio.
</p>
</body>
</subsection>
<subsection>
<title>Init no puede cargar la directriz SELinux</title>
<body>
<p>
Durante el inicio del sistema, el proceso <c>init</c> es el responsable
de cargar e interactuar con la directriz SELinux en memoria. Si
<c>init</c> no soporta SELinux, su entorno no dispondrá de soporte
para SELinux.
</p>
<p>
Para verificar si <c>init</c> soporta SELinux, necesitamos comprobar si
utiliza el objeto compartido <path>libselinux.so</path>:
</p>
<pre caption="Comprobar si init soporta SELinux">
~# <i>ldd /sbin/init</i>
linux-vdso.so.1 => (0x00006ace30e84000)
<comment>( Debería ver algo similar a la siguiente línea: )</comment>
libselinux.so.1 => /lib/libselinux.so.1 (0x00006ace30a46000)
libc.so.6 => /lib/libc.so.6 (0x00006ace306e9000)
libdl.so.2 => /lib/libdl.so.2 (0x00006ace304e5000)
/lib64/ld-linux-x86-64.so.2 (0x00006ace30c68000)
</pre>
<p>
Si éste no es el caso, asegúrese de que <c>emerge --info</c> muestra que
el ajuste USE selinux está en su sitio y reinstale
<path>sys-apps/sysvinit</path>. Si este ajuste no está definido,
compruebe su perfil Gentoo y asegúrese de que apunta a un perfil
<path>selinux/v2refpolicy/...</path>.
</p>
</body>
</subsection>
</section>
<section>
<title>No se puede ingresar en el sistema</title>
<subsection>
<title>Descripción del problema</title>
<body>
<p>
Si no puede ingresar en el sistema en una situación en particular
(en remoto, en local, como root, como usuario regular,...) puede que
se esté encontrando con algún problema sin mucha importancia. Sin
embargo, para resolverlo tendrá que ingresar en el sistema como
<e>sysadm_r</e> de un modo u otro.
</p>
<p>
Si no puede ingresar como un usuario <e>sysadm_r</e>, deshabilite
SELinux (arranque con <c>enforcing=0</c>) de este modo no se realiza
ningún forzado SELinux. Los cambios que haga en modo permisivo son
igual de efectivos que en el modo forzado (enforcing).
</p>
</body>
</subsection>
<subsection>
<title>Contexto incorrecto</title>
<body>
<p>
En la mayoría de los casos encontrará que el problema es un contexto de
seguridad incorrecto. Ejecute <c>sestatus -v</c> y compare los
<e>contextos de proceso</e> o los <e>contextos de fichero</e> que
observe con los dados en la siguiente tabla.
</p>
<table>
<tr>
<th>Proceso</th>
<th>Contexto</th>
<th>Si el contexto no es el adecuado...</th>
</tr>
<tr>
<ti>Contexto init</ti>
<ti>system_u:system_r:init_t</ti>
<ti>
En primer lugar, verifique que el propio init está correctamente
etiquetado. Compruebe la salida de la ejecución anterior de
la orden <c>sestatus -v</c> para el fichero
<path>/sbin/init</path> y asegúrese de que está ajustado a
system_u:object_r:init_exec_t. Si este no es el caso, etiquete de
nuevo <path>sys-apps/sysvinit</path> usando <c>rlpkg sysvinit</c>.
Haga las mismas comprobaciones que se realizan en la sección
<uri link="#doc_chap1">No se puede cargar la directriz de SELinux
</uri>. Reinicie su sistema e inténtelo de nuevo.
</ti>
</tr>
<tr>
<ti>Contexto agetty</ti>
<ti>system_u:system_r:getty_t</ti>
<ti>
Asegúrese de que el binario <path>/sbin/agetty</path> esta etiquetado
como system_u:object_r:getty_exec_t. Si no es así, etiquete de nuevo
el paquete <path>sys-apps/util-linux</path> usando
<c>rlpkg util-linux</c>. A continuación reinicie todos los procesos
agetty usando <c>pkill agetty</c> (estos procesos se pondrán en
marcha de nuevo automáticamente).
</ti>
</tr>
<tr>
<th>Fichero</th>
<th>Contexto</th>
<th>Si el contexto no es el adecuado...</th>
</tr>
<tr>
<ti>/bin/login</ti>
<ti>system_u:object_r:login_exec_t</ti>
<ti>
El binario login forma parte de <path>sys-apps/shadow</path>.
Ejecute <c>rlpkg shadow</c> para etiquetar de nuevo los ficheros de
este paquete y reintente el ingreso en el sistema.
</ti>
</tr>
<tr>
<ti>/sbin/unix_chkpwd</ti>
<ti>system_u:object_r:chkpwd_exec_t</ti>
<ti>
Este binario es parte del paquete <path>sys-libs/pam</path> y SSH lo
utiliza cuando se configura para que use PAM a la hora de realizar
la autenticación de usuarios. Etiquete de nuevo el paquete usando
<c>rlpkg pam</c> e intente de nuevo el ingreso en el sistema.
</ti>
</tr>
<tr>
<ti>/etc/passwd</ti>
<ti>system_u:object_r:etc_t</ti>
<ti rowspan="2">
Tanto <path>/etc/passwd</path> como <path>/etc/shadow</path> deben
estar etiquetados correctamente, de lo contrario PAM no podrá
autenticar a ningún usuario. Etiquete de nuevo los ficheros con
<c>restorecon /etc/passwd /etc/shadow</c> e intente de nuevo el
ingreso en el sistema.
</ti>
</tr>
<tr>
<ti>/etc/shadow</ti>
<ti>system_u:object_r:shadow_t</ti>
</tr>
<tr>
<ti>/bin/bash</ti>
<ti>system_u:object_r:shell_exec_t</ti>
<ti>
El intérprete de comandos del usuario (en este caso, <c>bash</c>)
se debe etiquetar correctamente de modo que el usuario pueda cambiar
al dominio de usuario cuando ingrese en el sistema. Para hacer esto,
etiquete de nuevo el paquete <path>app-shells/bash</path> usando
<c>rlpkg bash</c>. Entonces puede intentar de nuevo el ingreso en el
sistema.
</ti>
</tr>
</table>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-intro-concepts.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-concepts.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-concepts.xml?rev=1.1&content-type=text/plain
Index: hb-intro-concepts.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-concepts.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>3</version>
<date>2011-04-15</date>
<section>
<title>Introducción</title>
<subsection>
<title>Conceptos detrás de SELinux</title>
<body>
<p>
Debido a que SELinux es un sistema MAC, probablemente se habrá dado cuenta
de que la gestión de los permisos y privilegios basados en SELinux va
a ser un poco más complicada que la gestión de privilegios en un control
de acceso discrecional que es el que se utiliza generalmente en un sistema
Linux. Algo importante a tener en cuenta es que SELinux trabaja
<b>encima</b> del sistema DAC que es el que utiliza todo el mundo en Linux.
Siendo un administrador de sistemas, necesitará familiarizarse con algunos
conceptos y estructuras que SELinux ha colocado para gestionar el acceso
a estos sistemas.
</p>
<p>
El propósito de este capítulo es La descripción de estos conceptos. Daremos
ejemplos de estos conceptos en un sistema Gentoo Hardened con SELinux
habilitado. Sin embargo, no se preocupe si el uso de algunas órdenes
en particular no se detalla suficientemente. Se muestran únicamente como
ejemplos (lo que se aprenda de esto es más importante) y será discutido
más abajo en este documento.
</p>
</body>
</subsection>
</section>
<section>
<title>Contextos de seguridad</title>
<subsection>
<title>Usuarios, Roles y Dominios</title>
<body>
<p>
Uno de los primeros conceptos con los que debe familiarizarse es el
de <e>contexto de seguridad</e>. Se trata de un estado que se asigna
a un recurso de modo que identifica únicamente qué concesiones (permisos)
se dan al recurso. Este contexto es extremadamente importante para
SELinux ya que es la definición en la cual basa sus permisos (concesiones
o revocaciones). Cuando un recurso no tiene un contexto asignado, SELinux
intentará darle un contexto de seguridad por defecto, el cual, considerando
la filosofía del menor privilegio posible, tiene pocos permisos para
realizar cualquier acción.
</p>
<p>
En el marco de SELinux, este contexto de seguridad se muestra usando tres
definiciones:
</p>
<dl>
<dt>user</dt>
<dd>
El <e>usuario SELinux</e> (no el mismo que el usuario técnico de
Linux/Unix) asignado al recurso.
</dd>
<dt>role</dt>
<dd>
El rol SELinux en el que el recurso trabaja actualmente.
</dd>
<dt>type</dt>
<dd>
El tipo asignado al recurso, la clave para las reglas de reforzamiento
de SELinux.
</dd>
</dl>
<p>
Se dará más información sobre estas definiciones en particular a lo largo
de este capítulo.
</p>
<p>
Como ejemplo, echemos un vistazo al contexto de seguridad de un usuario
que ha ingresado en el sistema:
</p>
<pre caption="Obtener el contexto de seguridad de un usuario que ha ingresado en el sistema">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
</pre>
<p>
En este caso, el usuario está identificado como el usuario SELinux
<e>staff_u</e>, que actualmente tiene el rol <e>staff_r</e> y está
asignado al tipo <e>staff_t</e>. Las acciones que se permiten a este
usuario están basadas en este contexto de seguridad.
</p>
</body>
</subsection>
<subsection>
<title>Directrices de control de acceso</title>
<body>
<p>
Como ya se ha mencionado, estos contextos de seguridad se usan como
base de las reglas de permisos. Lo que hace SELinux es comprobar el
contexto de seguridad de la fuente (por ejemplo un proceso) y del
destino (por ejemplo un fichero que el proceso necesita leer). Entonces
se comprueba si la operación solicitada (lectura) está permitida entre
estos dos contextos. Recuerde que SELinux trabaja encima del sistema
de permisos estándar usados en Linux. Si un proceso no puede, en
principio, leer un fichero, ni siquiera se consulta a SELinux.
</p>
<p>
Hasta ahora, el contexto de seguridad define el estado de un recurso,
sin embargo, no hemos hablado de los recursos en sí. En el marco de
SELinux, los tipos de recursos están definidos como
<e>clases de objetos</e>. Ejemplos muy comunes son <e>file</e>
o <e>dir</e>. SELinux también gestiona clases como
<e>filesystem</e>, <e>tcp_socket</e>, <e>process</e>, <e>sem</e>
(semáforos) y mucho más.
</p>
<p>
En cada clase de objeto, se declara un conjunto de <e>permisos</e>, los
cuales son aplicables a un recurso de esta clase de objeto. Por ejemplo,
la clase de objeto <e>process</e> soporta cuanto menos los siguientes
permisos:
</p>
<pre caption="Permisos soportados para un recurso 'process'">
~# <i>ls /selinux/class/process/perms</i>
dyntransition getcap rlimitinh setpgid siginh
execheap getpgid setcap setrlimit sigkill
execmem getsched setcurrent setsched signal
execstack getsession setexec setsockcreate signull
fork noatsecure setfscreate share sigstop
getattr ptrace setkeycreate sigchld transition
</pre>
<p>
Echemos un vistazo a un pequeño ejemplo que explica las reglas de permisos
y cómo las utiliza SELinux. El usuario ejemplo está en el contexto
<e>staff_u:staff_r:staff_t</e> y desea escribir en su propio directorio.
Lo lógico sería que se le permitiera esta acción. No se preocupe por las
órdenes mostradas aquí, las discutiremos en detalle más abajo en este
mismo documento.
</p>
<pre caption="Comprobar si un usuario puede escribir en su propio directorio home">
<comment>(Muestra el contexto de seguridad para el directorio home del usuario)</comment>
~$ <i>ls -dZ ${HOME}</i>
staff_u:object_r:user_home_dir_t /home/swift
<comment>(Busca la regla que permite al tipo staff_t escribir en un directorio con el tipo user_home_dir_t type)</comment>
~$ <i>sesearch -s staff_t -t user_home_dir_t -c dir -p write -A</i>
Found 1 semantic av rules:
allow staff_t user_home_dir_t : dir { ioctl read write create ... };
</pre>
<p>
Como era de esperar, el contexto de seguridad del usuario (para ser más
específico, el dominio en el que reside) tiene acceso de escritura al
dominio de los directorios destino. La noción de <e>dominio</e> aparece
frecuentemente en la documentación de SELinux y se refiere al tipo
asignado a un proceso. Por cierto, como los ficheros no tienen ningún
rol, SELinux les asigna el rol por defecto <e>object_r</e>.
</p>
<p>
Ahora echemos un vistazo al siguiente ejemplo. Nuestro usuario, que
pertenece al grupo portage, quiere escribir en el directorio
<path>/var/tmp/portage</path>:
</p>
<pre caption="Comprobar si un usuario puede escribir en el directorio /var/tmp/portage">
~$ <i>id -a</i>
uid=1001(swift) gid=100(users) groups=100(users),...,250(portage),...
~$ <i>ls -ldZ /var/tmp/portage</i>
drwxrwxr-x. 3 portage portage system_u:object_r:portage_tmp_t 4096 Dec 6 21:08 /var/tmp/portage
</pre>
<p>
Desde le punto de vista de los permisos estándar de Linux, el usuario
tiene permiso para escribir. Pero, ¿Le permitirá SELinux hacerlo?
</p>
<pre caption="Intentar escribir en /var/tmp/portage">
~$ <i>sesearch -s staff_t -t portage_tmp_t -c dir -p write -A</i>
~$
<comment>(Observe que no se obtiene ninguna información)</comment>
~$ <i>touch /var/tmp/portage/foo</i>
touch: no se puede efectuar `touch' sobre «/var/tmp/portage/foo»: Permiso denegado
</pre>
<p>
Como SELinux no pudo encontrar una regla que permitiera al dominio
staff_t escribir en cualquier directorio etiquetado con el tipo
portage_tmp_t type, se denegó el acceso.
</p>
</body>
</subsection>
</section>
<section>
<title>Forzado de tipos / Tipos de dominio</title>
<subsection>
<title>Tipos y dominios</title>
<body>
<p>
Para explicar como funcionan las reglas de permisos y como se fuerzan
mediante los contextos de seguridad, comencemos con la última definición
en el contexto (el <e>tipo</e>) y trabajemos hacia los roles y usuarios.
</p>
<ul>
<li>
Un <e>tipo SELinux</e> es una etiqueta en particular que se asigna
a un recurso. Por ejemplo, la orden <c>passwd</c> está etiquetada
con el tipo passwd_exec_t.
</li>
<li>
Un <e>dominio SELinux</e> es el estado de seguridad de un proceso e
identifica los derechos y permisos que posee. Normalmente, nos
referiremos a él por su declaración de tipo. Por ejemplo, el dominio
para una orden <c>passwd</c> es passwd_t.
</li>
</ul>
<p>
Las reglas que identifican las acciones permitidas para un dominio tienen
la siguiente sintaxis:
</p>
<pre caption="Reglas estándar de las directrices SELinux">
allow <src_domain> <dst_type> : <class> { permiso [ permiso [ ... ] ] } ;
</pre>
<p>
Un ejemplo del dominio <e>passwd_t</e> podrían ser los permisos
concedidos entre el dominio <e>passwd_t</e> y el tipo <e>shadow_t</e>
(usado por el fichero <path>/etc/shadow</path>).
</p>
<pre caption="Concesiones entre passwd_t y shadow_t">
allow passwd_t shadow_t : file { ioctl read write create ... } ;
</pre>
<p>
Esta sintaxis de permisos es muy potente, pero también complicada. Para
tener un sistema seguro en el que se permite un comportamiento normal,
necesitará ajustar finamente estas reglas para todas y cada una de las
aplicaciones (y de igual forma para los dominios) que desea albergar en
su sistema. Dar permisos de forma extensiva a un dominio en un tipo
en particular, puede resultar en la pérdida de eficiencia e incluso
de efectividad.
</p>
<p>
Para soportar reglas de concesión de forma más secilla, SELinux permite
el agrupamiento de tipos usando los atributos de tipos. Por ejemplo, el
atributo <e>exec_type</e> agrupa todos los tipos que se asignan a los
ficheros ejecutables (como <e>bin_t</e>, <e>ssh_exec_t</e>, ...), mientras
que el atributo <e>file_type</e> agrupa todos los tipos que se asignan
a ficheros regulares. Aunque esto pueda simplificar la gestión de las
reglas, puede resultar en que se asignen sin quererlo más permisos de
los que se desean asignar.
</p>
</body>
</subsection>
<subsection>
<title>Transiciones de dominio</title>
<body>
<p>
Hasta aquí hemos hablado de tipos, definiciones de dominios y sus permisos.
Hemos comentado previamente que los permisos están basados en el dominio
en el que reside un proceso. Pero, ¿cómo llega un proceso a ser parte de
un dominio? Podrá pensar que esto ocurre de una forma prefijada (ejecutar
la orden <c>passwd</c> conllevaría que el proceso se asociara al
dominio <e>passwd_t</e>), de hecho, esto se realiza mediante la combinación
de tres privilegios muy específicos que deben ser concedidos:
</p>
<ol>
<li>
Se debe permitir al dominio actual la transición a otro dominio.
</li>
<li>
El dominio destino debe tener un <e>punto de entrada</e>, que es
un ejecutable, al cual se le permite arrancar en el dominio.
</li>
<li>
El dominio fuente debe tener permisos de <e>ejecución</e> (en el
dominio) sobre ese ejecutable.
</li>
</ol>
<impo>
El hecho de que no se permita la transición, no significa que no se pueda
ejecutar el binario. El binario puede ser ejecutado, pero no lo hará
dentro del dominio destino. En lugar de eso, heredará el dominio del
ejecutor y por lo tanto los permisos y derechos de ese dominio.
</impo>
<p>
Usando estas reglas, el administrador de la seguridad de un sistema puede
controlar de forma más específica quién y bajo qué condiciones se pueden
realizar acciones particulares.
</p>
</body>
</subsection>
</section>
<section>
<title>Roles y derechos</title>
<subsection>
<title>El rol de un rol</title>
<body>
<p>
Los dominios y las reglas de dominio expuestas anteriormente son bastante
potentes. Sin embargo, SELinux ofrece mucho más. Después de todo, debe
ser posible denegar el acceso a dominios particulares a usuarios no
autorizados. Un requisito es, desde luego, no permitir transiciones desde
el dominio del usuario a un dominio restringido, pero, ¿cómo se permite
a un conjunto de usuarios mientras que se deniega a otro?
</p>
<p>
Presentaremos los roles. Usando roles, puede indicarle a SELinux qué
dominios se permiten para un rol y cuales no. Un ejemplo podría ser el
dominio <e>ifconfig_t</e>. Este dominio tiene los derechos para cambiar
las definiciones de las interfaces de red, lo cual es algo que no debe
permitir a sus usuarios. Y, de hecho, si pudiera verificarlo, SELinux
no permite asignar el rol de usuario <e>user_r</e> al dominio
<e>ifconfig_t</e>.
</p>
<pre caption="Comparación de user_r y sysadm_r para el dominio ifconfig_t">
~$ <i>seinfo -ruser_r -x</i>
user_r
Dominated Roles:
user_r
Types:
...
~$ <i>seinfo -rsysadm_r -x</i>
sysadm_r
Dominated Roles:
sysadm_r
Types:
...
ifconfig_t
...
</pre>
<impo>
De nuevo, el hecho de no poder asociar un dominio, no significa que el rol
<e>user_r</e> no pueda <e>ejecutar</e> el binario <c>ifconfig</c>. Puede,
pero ejecutará este binario en su propio dominio (<e>user_t</e>). Este
dominio no tiene derechos para manipular la interfaces de red (sin
embargo puede leer información del interfaz aunque con información
limitada).
</impo>
<p>
Los roles se usan a menudo en sistemas de control de acceso para agrupar
permisos en un solo conjunto funcional (el rol), el cual se puede asignar
a individuos (cuentas). Por ejemplo, estos sistemas de control de acceso
crean roles para contables, operadores, administradores,... y conceden los
privilegios apropiados a estos roles. Entonces, a estos usuarios se les
asigna uno (o a veces varios) roles y los usuarios heredan los permisos
asignados a estos roles.
</p>
<p>
En SELinux, se usa esta idea (se usan roles para diferenciar privilegios
de forma funcional), sin embargo se implementa de forma distinta: a los
roles se le asignan dominios destino en los que se permite que un rol
"pueda entrar". Los permisos permanecen asignados a los dominios.
</p>
</body>
</subsection>
<subsection>
<title>Transiciones de rol</title>
<body>
<p>
Los usuarios (y los procesos) pueden cambiar de rol. En SELinux se permite,
pero únicamente cuando se concede la posibilidad de cambiar. Por defecto,
las directrices de SELinux usadas en Gentoo Hardened ofrecen cinco roles
en un sistema SELinux:
</p>
<dl>
<dt>object_r</dt>
<dd>
El rol <e>object_r</e> es el único rol disponible por defecto en
SELinux. Normalmente solo se asigna a recursos en los que no se
puede obtener ningún valor o rendimiento del sistema de roles (como
en ficheros y directorios).
</dd>
<dt>system_r</dt>
<dd>
El rol <e>system_r</e> se usa para servicios del sistema con muchos
privilegios. Se permite al rol <e>system_r</e> cambiar a cualquier
otro rol definido por "defecto". Ningún rol excepto <e>sysadm_r</e>
puede cambiar al rol <e>system_r</e>.
</dd>
<dt>sysadm_r</dt>
<dd>
El rol <e>sysadm_r</e> se usa para actividades de administración del
sistema. Se permite al rol <e>sysadm_r</e> cambiar a cualquier otro
rol definido por "defecto". Únicamente se permite a los roles
<e>system_r</e> y <e>staff_r</e> cambiar al rol <e>sysadm_r</e>.
</dd>
<dt>staff_r</dt>
<dd>
El rol <e>staff_r</e> se asigna a los operadores del sistema que
deberían tener derechos para realizar tareas de administración.
Al rol <e>staff_r</e> se le permite cambiar únicamente al rol
<e>sysadm_r</e>. Solo <e>sysadm_r</e> y <e>system_r</e> pueden
cambiar al rol <e>staff_r</e>.
</dd>
<dt>user_r</dt>
<dd>
El rol <e>user_r</e> se asigna a usuarios estándar y sin muchos
privilegios. No se permite la transición a ningún otro rol; únicamente
se permite a los roles <e>sysadm_r</e> y <e>system_r</e> cambiar al
rol <e>user_r</e>.
</dd>
</dl>
<note>
Los roles por "defecto" son: <e>user_r</e>, <e>staff_r</e>,
<e>sysadm_r</e> y <e>system_r</e>. Si se crean roles adicionales, éstos
no serán parte del los roles por "defecto".
</note>
<p>
Usando estas definiciones, un usuario dentro del rol <e>user_r</e> nunca
podrá ejecutar <c>ifconfig</c> en el dominio <e>ifconfig_t</e>. El uso
de la palabra <e>nunca</e> es importante: no podrá, incluso si el usuario
puede usar la cuenta root mediante <c>sudo</c> o cualquier otra orden
que permita ejecutar <c>ifconfig</c> en el dominio <e>ifconfig_t</e>,
porque, a pesar de que ha ejecutado <c>sudo</c>, el usuario está
utilizando el rol <e>user_r</e>.
</p>
</body>
</subsection>
<subsection>
<title>Usuarios de SELinux</title>
<body>
<p>
Un usuario de SELinux no es lo mismo que un usuario Linux. Mientras que
se puede cambiar de una cuenta de usuario estándar de Linux a otra usando
órdenes como <c>su</c> o <c>sudo</c>, un usuario SELinux no se puede
cambiar. Incluso cuando ejecute con éxito <c>sudo</c>, su usuario SELinux
seguirá siendo el mismo.
</p>
<p>
Cuando observe un sistema gestionado con SELinux, podrá ver que ese
sistema no tiene muchos usuarios SELinux. Por ejemplo, la configuración
por defecto de Gentoo Hardened define los usuarios <e>root</e>,
<e>user_u</e>, <e>staff_u</e>, <e>sysadm_u</e> y <e>system_u</e> y en
muchos sistemas nunca se crea ningún usuario SELinux más. En este caso,
¿la ventaja mencionada arriba sobre usuarios SELinux (una vez que el
usuario ingresa en el sistema, éste no puede cambiar a otro usuario
SELinux) es la única?
</p>
<p>
Bien, no. Los usuarios SELinux también se usan para categorizar las
cuentas que tienen el permiso de usar un rol en particular.
</p>
<pre caption="Usuarios SELinux y sus roles asociados">
~# <i>semanage user -l</i>
SELinux User SELinux Roles
root staff_r sysadm_r
staff_u staff_r sysadm_r
sysadm_u sysadm_r
system_u system_r
user_u user_r
</pre>
<p>
Los usuarios Linux estándar están vinculados a estos usuarios SELinux:
</p>
<pre caption="Usuarios Linux y sus vínculos con usuarios SELinux">
~# <i>semanage login -l</i>
Login Name SELinux User
__default__ user_u
root root
swift staff_u
</pre>
<p>
En este ejemplo, únicamente el nombre de los usuarios Linux <e>swift</e>
(a través de <e>staff_u</e>) y <e>root</e> (a través del usuario SELinux
<e>root</e>) podrán eventualmente trabajar en el rol <e>sysadm_r</e>. El
resto de cuentas serán vinculadas por defecto al usuario <e>user_u</e>
(y al rol <e>user_r</e>).
</p>
<p>
Esto se aplica <e>únicamente</e> a los usuarios interactivos. Los procesos
que se lanzan mediante un guión de inicio o de cualquier otra forma no
se asocian con el usuarios SELinux <e>user_u</e>: dependiendo del contexto
de seguridad de los procesos que los lancen, podrán cambiar a cualquier
otro. Desde luego, si el contexto de seguridad del proceso que los está
lanzando es <e>user_u:user_r:user_t</e> entonces no podrán transformarse
en otro más que <e>user_u:user_r:*</e> con <e>*</e> un dominio soportado
por el rol <e>user_r</e>.
</p>
<p>
Los usuarios SELinux se utilizan también para implementar el <e>Control
de Acceso Basado en Usuario</e> o <e>UBAC</e>. Esta funcionalidad de
SELinux permite a los dominios conocer a los usuarios: un proceso
corriendo en el contexto de un usuario SELinux en particular puede, por
ejemplo, únicamente trabajar con ficheros del mismo usuario SELinux. Esto
ofrece un método de acceso más fino ya que ese proceso podrá correr en un
dominio que tenga acceso al dominio del fichero, pero no podrá escribir
en el fichero ya que el usuario SELinux es distinto.
</p>
</body>
</subsection>
</section>
<section>
<title>Seguridad multinivel / Seguridad multicategoría</title>
<subsection>
<title>Introducción</title>
<body>
<p>
Además de la característica para forzar los tipos, SELinux también ofrece
soporte MLS (seguridad multinivel) y MCS (seguridad multicategoría). Esto
permite a los administradores definir una directriz de confidencialidad
jerárquica. Por ejemplo, puede asegurarse de que un proceso o usuario en
un determinado dominio de seguridad y nivel, pueda escribir en ficheros
del mismo nivel (o superior), o leer ficheros del mismo nivel (o inferior),
pero no puede escribir en ficheros de un nivel inferior. Esto permite a
los administradores implementar un nivel de seguridad jerárquica
pública/interna/confidencial/estrictamente confidencial para los ficheros.
</p>
<p>
Aunque la implementación de MLS podría realizarse usando las reglas de
forzado de tipos que hemos explicado previamente, hacerlo así podría
desembocar en una colección inmanejable de tipos y permisos.
La implementación MLS lo facilita.
</p>
<p>
Actualmente, el manual de SELinux para Gentoo Hardened no cubre
MLS/MCS, pero esto puede cambiar en el futuro (y probablemente lo hará).
</p>
</body>
</subsection>
</section>
<section>
<title>Siguientes pasos</title>
<subsection>
<title>Qué es lo siguiente</title>
<body>
<p>
Puede que sea difícil comprenderlos ahora, pero estos conceptos son
importantes ya que si algo va mal en su sistema cuando habilite SELinux,
pero todo funciona bien cuando se deshabilita, entonces necesitará
estudiar más a fondo los contextos de seguridad, las reglas, los tipos
y transiciones de dominio para averiguar el motivo del fallo.
</p>
<p>
En el siguiente capítulo discutiremos como las distribuciones del tipo
Gentoo Hardened gestionan las distintas reglas de permisos y cómo
usan un lenguaje de macros para generar los permisos en lugar de
crear las reglas una a una.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-intro-enhancingsecurity.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-enhancingsecurity.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-enhancingsecurity.xml?rev=1.1&content-type=text/plain
Index: hb-intro-enhancingsecurity.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-enhancingsecurity.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>1</version>
<date>2011-01-10</date>
<section>
<title>Introducción</title>
<subsection>
<title>Una bienvenida amigable</title>
<body>
<p>
Bienvenido al manual de SELinux para Gentoo. Con este recurso
queremos presentarle rápidamente la implementación de SELinux y
las directrices implicadas. Parte de esta presentación consiste
en ayudarle a comprender porqué se creó SELinux y qué conceptos se
esconden detrás de los parches de SELinux. Cubriremos los conceptos
más importantes de SELinux, las directrices de referencia que utiliza
Gentoo Hardened y desarrollaremos el trabajo con algunas herramientas
de SELinux.
</p>
<p>
El propósito de este libro no es explicar en detalle el funcionamiento
del propio SELinux. Existen muchas referencias disponibles en Internet
y en muchos libros que le ayudarán con SELinux. En lugar de esto, nos
centraremos en la integración de SELinux en Gentoo Hardened. Desde
luego, le ofreceremos una rápida introducción a SELinux para que
pueda comprender cómo trabaja, lo que es, y le ayudaremos a identificar
las acciones que necesita realizar para asegurar su sistema usando
las herramientas de SELinux.
</p>
</body>
</subsection>
</section>
<section>
<title>Asegurando Linux</title>
<subsection>
<title>Seguridad en general</title>
<body>
<p>
La seguridad se ve a menudo como un concepto vago. ¿Qué es la seguridad
en general? ¿Cómo se mide? ¿Qué beneficio se obtiene y cómo asegurarse
de no poner demasiado esfuerzo en asegurar su sistema?
</p>
<p>
Bien, los fanáticos de la seguridad le contarán que no existe otra
cosa salvo el exceso de seguridad. Si se implementa de forma correcta,
la seguridad no restrige la funcionalidad o el rendimiento. No le da
demasiado trabajo para realizar sus tareas. Pero implementar la
seguridad de forma apropiada es una tarea diferente y que conlleva
mucho tiempo. Esta es la razón por la que en muchas ocasiones se
escucha que la seguridad es tan buena como su administrador.
</p>
<p>
Entonces, ¿Cómo puedo velar por la seguridad?. Una buena práctica
consiste en definir sus metas en lo que a seguridad se refiere. Haga
una lista de que lo que quiere conseguir y porqué lo quiere hacer.
Haciendo un seguimiento de las amenazas que quiere minimizar, podrá
construir un modelo de seguridad que es el adecuado para su entorno.
Estas amenazas pueden ser muy pretenciosas, como por ejemplo
"Asegurarse de que nadie pueda violar nuestras medidas de seguridad".
</p>
<p>
En el caso de un sistema Linux funcionando con SELinux, esto podría
significar que desea que nadie o nada, salvo los procesos de confianza,
puedan escribir en ficheros críticos del sistema, como por ejemplo,
la(s) imagen(es) del núcleo, configuración del gestor de arranque,
las contraseñas y el propio binario de SELinux con las directrices.
</p>
</body>
</subsection>
<!-- Suggestion to remove from guide, more interesting for a generic security
document?
<subsection>
<title>Security on Operating System Level</title>
<body>
<p>
So far for the high-level and theoretic explanation on security. What about
operating system security?
</p>
<p>
On the Internet, you will find a multitude of documents helping you secure your
system. Some of these documents are procedure-driven (execute this, delete that,
change permissions of this file and that file) and are often found as security
best practices for operating systems or distributions. You can find such
documents on the project sites themselves (such as the <uri
link="/doc/en/security/security-handbook.xml">Gentoo Security Handbook</uri>) or
on specialized sites of organizations that keep track of secure configuration
baselines in general (such as <uri
link="http://www.cisecurity.org">CISecurity</uri>'s benchmark documents).
Others are higher-level descriptions (often called frameworks) that help you
focus on the various fields in which security plays a role.
</p>
<p>
A simple example of such higher-level descriptions can be seen in the CoBIT
framework, which has a process called <e>Ensure Systems Security</e> which
defines (at least) the following control objectives:
</p>
<ol>
<li>Manage Security Measures</li>
<li>Identification, Authentication and Access</li>
<li>Security of Online Access to Data</li>
<li>User Account Management</li>
<li>Management Review of User Accounts</li>
<li>User Control of User Accounts</li>
<li>Security Surveillance</li>
<li>Data Classification</li>
<li>Central Identification and Access Rights Management</li>
<li>Violation and Security Activity Reports</li>
<li>Incident Handling</li>
<li>Re-accreditation</li>
<li>Counterparty Trust</li>
<li>Transaction Authorization</li>
<li>Non-repudiation</li>
<li>Trusted Path</li>
<li>Protection of Security Functions</li>
<li>Cryptographic Key Management</li>
<li>Malicious Software Preventions, Detection and Correction</li>
<li>Firewall Architectures and Connections with Public Networks</li>
<li>Protection of Electronic Value</li>
</ol>
<p>
If your head is not spinning yet, then I suggest to dive deeper into these
subjects. However, for this handbook, we'll leave it at this and focus on those
topics that are relevant for further SELinux discussions.
</p>
</body>
</subsection>
<subsection>
<title>Operating System Security Best Practices</title>
<body>
<p>
To properly secure any operating system, there are a few best practices that you
might need to keep in mind. They do not cover the full spectrum of configuration
directives or requirements, but if you do not implement those properly, you risk
that the threats facing your system become reality faster.
</p>
<dl>
<dt>Only run necessary services</dt>
<dd>
Only run services (scripts, daemons, jobs, servers ...) of which you know
you need them. Regularly verify your system runtime behavior to see if no
services are running that you don't need. The more services that run, the
more <e>access vectors</e> intruders or malicious people have towards your
system.
</dd>
<dt>Update your system regularly</dt>
<dd>
Updating your system will resolve all potential vulnerabilities of software
you have if they were known by the developers and fixed in later versions.
Some distributions, including Gentoo, allow you to pull in only
security-related updates so that your upgrade cycle is not too time and
resource consuming. See <c>glsa-check</c> for more information on how to do
this with Gentoo.
</dd>
<dt>Do not use privileged accounts</dt>
<dd>
For each task you execute on a system, make sure that that task has the
least amount of privileges needed to get to its goal. Only a few services
will require root privileges (Unix/Linux' highest privileged account), but
other accounts might also be seen as privileged (such as accounts that have
password-less <c>sudo</c> rights, or accounts that are in the <e>wheel</e>
group. The same is true for your regular day-to-day tasks.
</dd>
<dt>Implement a good password policy</dt>
<dd>
Make sure that your passwords are not easy to guess or to brute-force. If
your system uses passwords for authentication and the password is
compromised, security is completely compromised as well as, as far as the
system knows, the malicious user that is using your password is you.
</dd>
<dt>Configure your services properly</dt>
<dd>
Do not trust services to come with a good, default configuration. Most
default configurations are so that the majority of users can use the service
(feature-wise), which might not always be the proper configuration for you.
</dd>
<dt>Use proper permissions</dt>
<dd>
Make sure your files are properly protected permission-wise. Never use
world-readable files and only allow other accounts to read (or modify) your
file(s) if they need to. Use group-permissions wisely and often validate
group membership. If file systems can be used in a read-only fashion, do so.
If you do not need to access a particular file system by default, don't
mount it.
</dd>
</dl>
<p>
This is just a subset of best practices. One of the aspects within an operating
system setup is the method of <e>accessing</e> the system, services or data.
Implementing a good access control is mandatory from a systems' security
point-of-view.
</p>
</body>
</subsection>
-->
<subsection>
<title>Control de acceso</title>
<body>
<p>
Un control de acceso decente de un sistema (o grupo de sistemas),
asegura que únicamente se permite acceso a las personas o procesos
autorizados a los recursos con los que quieren trabajar.
</p>
<p>
Antes de que pueda implementar un control de acceso al sistema,
necesitará obtener la autorización adecuada. Si sus esquemas de
autenticación fallan, su sistema de control de acceso al sistema
podría no diferenciar a los usuarios legítimos de los maliciosos.
</p>
<p>
La autenticación de los usuarios en los sistemas Linux se realiza
a través de PAM (<e>Módulos de Autenticación Enchufables</e>), un
potente mecanismo para integrar esquemas múltiples de autenticación
de bajo nivel en una interfaz de alto nivel.
</p>
<p>
Sin embargo, la autorización para el uso de los recursos, se realiza
a veces a través de un esquema simple de permisos. La mayoría de los
recursos no están ocultos por defecto, aunque existen parches y
actualizaciones (tales como las ofrecidas por las fuentes del núcleo
Gentoo Hardened con parches grSecurity que incluyen soporte para este
tipo de medidas). Puede ocultar la existencia de archivos en todo
el sistema de ficheros asegurándose de que el directorio en el que
residen no es legible ni "ejecutable" por cuentas no autorizadas.
</p>
<p>
Este esquema de permisos por defecto tiene algunos inconvenientes
importantes. No le permite definir autorizaciones flexibles (únicamente
permite autorizaciones a tres niveles: propietario, grupo propietario
y cualquier otra cuenta) y además está limitada a los permisos
lectura/escritura/ejecución (aunque algunos atributos adicionales
están disponibles hoy en día).
</p>
<p>
Otro problema es que el esquema de permisos es <e>discrecional</e>, lo
que significa que los usuarios y procesos pueden cambiar las directrices
de seguridad.
</p>
<p>
Este esquema de permisos es suficiente Para la mayoría de usuarios y ha
demostrado ofrecer un método adecuado para gestionar las autorizaciones
de acceso. Si embargo, los inconvenientes que presenta han resultado
ser un agujero importante en lo que Linux ofrece.
</p>
</body>
</subsection>
</section>
<section>
<title>Control de acceso obligatorio</title>
<subsection>
<title>Entre en SELinux</title>
<body>
<p>
Si el control de acceso discrecional, abreviado <e>DAC</e>, mencionado
arriba no es suficiente (y si es riguroso con la seguridad, no lo
encontrará suficiente), entonces necesitará un sistema Control de Acceso
<e>Obligatorio</e> o <e>MAC</e>.
</p>
<p>
Cuando se usa un sistema MAC, se necesita permitir explícitamente las
actividades que un proceso quiere realizar en un recurso. Esto ofrece
mayor granularidad con los permisos y los recursos. A menudo
ofrecen no sólo soporte para ficheros, sino también para zócalos
(sockets), puertos, segmentos de memoria, colas, procesos, servicios
del núcleo, llamadas al sistema, dispositivos, sistemas de ficheros y
mucho más. La granularidad de las actividades soportadas es también
muy grande. Para los ficheros, esto incluye: añadir, crear, ejecutar,
escribir, enlazar, llamadas ioctl, obtener atributos (getattr), dar
valor a atributos (setattr), lectura, renombrado, bloqueo,... mientras
que para los zócalos (sockets) estos pueden ser: añadir, asociar (bind),
conectar, crear, escribir, enviar a, aceptar,... También, cuando se
utiliza un sistema MAC, ningún usuario ni proceso puede manipular las
directrices de seguridad por sí mismo: lo que el administrador ha
concedido no puede ser revocado.
</p>
<p>
Aquí es donde SELinux entra en juego. SELinux es una característica del
núcleo Linux que implementa, entre otras cosas, un sistema MAC para
controlar y gobernar el acceso a varios recursos. Usa un esquema de
permisos de denegación por defecto, de forma que se necesita conceder
explícitamente el acceso que ha solicitado un proceso.
</p>
<p>
SELinux permite igualmente un modelo de permisos más fino <b>encima
del</b> sistema tradicional DAC (el cual se usa también mientras SELinux
está en funcionamiento; en otras palabras: si el sistema tradicional
no permite ciertas actividades, éstas no serán permitidas incluso si
las directrices de SELinux permiten la acción).
</p>
</body>
</subsection>
<subsection>
<title>¿Qué es SELinux?</title>
<body>
<p>
Para dar soporte a este modelo fino de permisos, es lógico pensar que
se deben realizar cambios al núcleo Linux. Sí, gracias a la interfaz
del núcleo Linux <e>LSM</e> (<e>Módulos de Seguridad de Linux</e>), el
soporte para SELinux se añadió de forma muy sencilla desde el comienzo
de las series 2.6 del núcleo. SELinux se ha integrado en el árbol
principal del núcleo. Sin embargo, el soporte de SELinux y su utilización
son dos cosas muy diferentes.
</p>
<p>
Para identificar adecuadamente los recursos, SELinux necesita asignar
etiquetas a estos recursos. Cuando los recursos están en memoria, se
realiza principalmente en el núcleo Linux, sin embargo, para recursos
persistentes como ficheros, estas etiquetas deben localizarse en algún
lugar. En SELinux, se ha elegido usar atributos extendidos del fichero
(que son almacenados en el propio sistema de ficheros). La ventaja de
este enfoque es que la etiqueta permanece junto al fichero incluso si
éste cambia de nombre. Por el contrario, una desventaja de este enfoque
es que el sistema de ficheros debe soportar estos
<e>atributos extendidos</e>, los cuales no todos los sistemas de
ficheros poseen (o tienen activados).
</p>
<p>
SELinux también utiliza roles para gestionar el acceso a los recursos.
A un usuario que no tiene el rol de acceso a la administración del
sistema no se le debe permitir ejecutar cualquier actividad de
administración del sistema incluso si es capaz de escalar sus privilegios
(por ejemplo usando una aplicación con la capacidad set-uid). Para el
soporte de roles, SELinux requiere cambios en los servicios de
autenticación (PAM) y necesita almacenar en algún lugar las definiciones
de los roles y las autorizaciones.
</p>
<p>
Aparte del soporte en el núcleo y las etiquetas asignadas a los recursos
en el sistema de autorización, SELinux requiere también herramientas
específicas para consultar y manipular las etiquetas, gestión de
privilegios (por ejemplo la herramienta <c>sudo</c>), servicios del
sistema (como HAL o SysVInit) etc. Esto se traduce en un conjunto de parches
que se aplican a estas herramientas (y más) los cuales no son siempre parte
del código fuente principal de la aplicación.
</p>
</body>
</subsection>
<subsection>
<title>Gentoo Hardened y SELinux</title>
<body>
<p>
Gentoo Hardened ofrece SELinux integrado en la distribución. Cuando se
selecciona soporte para SELinux, Gentoo Hardened aplicará los parches
necesarios a las aplicaciones y le ayudará a (re)etiquetar sus ficheros y
otros recursos para que puedan ser gestionados por SELinux. Gentoo Hardened
también integra soporte SELinux en Portage, permitiendo que los nuevos
ficheros que se instalen sean etiquetados automáticamente y que se utilice
un entorno inofensivo (sandbox) para la construcción segura de los
paquetes.
</p>
<p>
Aparte del soporte tecnológico puro, esperamos que encuentre los documentos
de soporte, guías, experiencia y soporte en línea necesarios para usar
SELinux en Gentoo. No dude en entrar y decir ¡hola! en el canal de chat
<c>#gentoo-hardened</c> de la red IRC en Freenode o en nuestra lista de
correo.
</p>
<p>
Si piensa que SELinux es apropiado para sus pretensiones y quiere
probarlo usando Gentoo Hardened, por favor, continúe leyendo. En el
próximo capítulo le informaremos de como se ha "diseñado" la seguridad
en SELinux y cómo está estructurada conceptualmente. En capítulos
posteriores le ayudaremos con el lenguaje de autorización y las
directrices "base" con las que la mayoría de las distribuciones
comienzan y finalmente le ayudaremos a instalar, ejecutar y gestionar
un sistema SELinux con Gentoo Hardened.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-intro-referencepolicy.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-referencepolicy.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-referencepolicy.xml?rev=1.1&content-type=text/plain
Index: hb-intro-referencepolicy.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-intro-referencepolicy.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>0</version>
<date>2010-12-01</date>
<section>
<title>Sobre las directrices de SELinux</title>
<subsection>
<title>El lenguaje de las directrices de SELinux</title>
<body>
<p>
Tal y como se ha descrito anteriormente, SELinux utiliza el forzado de
tipos para describir el estado de su sistema. Esto se realiza dando a
cada recurso de su sistema (bien sea un proceso, un puerto de red, un
fichero o un directorio) un tipo especifico y describiendo las reglas en
las que los tipos puede trabajar con otros tipos.
</p>
<p>
Por ejemplo, la regla que permite a todos los usuarios comunes (que están
en el dominio user_t) ejecutar ficheros con la etiqueta bin_t:
</p>
<pre caption="Regla para permitir el ejecución de ficheros bin_t">
allow user_t bin_t:file { read execute open };
</pre>
<p>
Otras reglas soportadas son:
</p>
<ul>
<li>
<e>dontaudit</e> deshabilita el registro del mensaje (o mensajes)
de denegación.
</li>
<li>
<e>auditallow</e> permite el acceso a la vez que realiza el registro
del mismo (por defecto los registros de acceso no se guardan).
</li>
<li>
<e>neverallow</e> fuerza a que una determinada regla no pueda ser
concedida. Aunque SELinux es un modelo de seguridad positivo (usa
listas blancas), en algunas ocasiones las reglas neverallow pueden
ser necesarias. Generalmente estas reglas no se utilizan.
</li>
</ul>
<p>
como puede imaginar, definir todas las reglas necesarias por un sistema
consume muchos recursos si se desea hacer correctamente. No solo
requiere un estudio en profundidad del funcionamiento del sistema, sino
también bastante tiempo para escribir y realizar pruebas. Pero quizás donde
se emplea más tiempo es en la escritura de las mismas reglas una y otra
vez para dominios distintos. Para ayudar a los desarrolladores en la
escritura de directrices, se ha creado una <e>directriz de referencia</e>
con las siguientes funcionalidades que son necesarias:
</p>
<ul>
<li>
el desarrollo de las reglas para las directrices de SELinux debe ser
centralizado incluso para distintas distribuciones.
</li>
<li>
Se debe soportar un lenguaje de macros que haga más sencillo escribir
nuevas directrices.
</li>
<li>
las directrices deben ser modulares, permitiendo añadir o eliminar
nuevas reglas.
</li>
</ul>
<p>
Centralizando el desarrollo de reglas para las directrices SELinux, los
usuarios de SELinux usarán el mismo convenio para el nombrado de dominios
en todas las distribuciones. Esto hace más fácil la depuración, realizando
bastante menos documentación y haciendo un poco más fácil que los usuarios
finales se familiaricen con SELinux.
</p>
</body>
</subsection>
<subsection>
<title>La directriz de referencia de Tresys</title>
<body>
<p>
La directriz de referencia por excelencia es la <uri
link="http://oss.tresys.com/projects/refpolicy">Directriz de Referencia
SELinux de Tresys</uri>. Esta directriz de referencia (actualmente
en su versión principal 2) es usada por prácticamente todas las
distribuciones que soportan SELinux, incluyendo Gentoo Hardened, Fedora,
RedHat Enterprise Linux, Debian, Ubuntu y otras. Esta implementación no
solo ofrece las directrices modulares que el usuario busca, sino que
también mejora la experiencia con SELinux mediante herramientas de
desarrollo que hacen más fácil trabajar con las directrices de SELinux en
su sistema.
</p>
<p>
La directriz de referencia comienza con una directriz <e>base</e> denominada
<path>base.pp</path>. Se trata de una colección de directrices necesarias
para tener un sistema preparado y en funcionamiento y que ofrece las
funciones necesarias para su orientación modular. En Gentoo Hardened, esta
directriz base se ofrece mediante <c>selinux-base-policy</c>.
</p>
<p>
Los módulos de directriz también utilizan la extensión <path>.pp</path> y
se nombran apropiadamente de acuerdo a lo que contienen. Por ejemplo, el
módulo de la directriz que contiene todas las reglas para la aplicación
<c>screen</c>, se llama <path>screen.pp</path>. Sin embargo, no todos los
módulos de directriz se denominan igual que la herramienta en cuestión:
el módulo de directriz que contiene las reglas especificas para
<c>wpa_supplicant</c> se denomina <path>networkmanager.pp</path>. En
Gentoo Hardened, los módulos de directriz están disponibles en la
categoría <path>sec-policy</path> y se llaman
<path>selinux-<módulo></path>.
</p>
<p>
Para obtener una lista de los módulos que se están ejecutando, teclee la
orden <c>semodule</c>:
</p>
<pre caption="Listando las directrices modulares de SELinux que se hallan en ejecución">
~# <i>semodule -l</i>
dbus 1.14.0
dnsmasq 1.9.0
hal 1.13.0
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Conmutar los estados de la directriz</title>
<body>
<p>
Debido a que las directrices se construyen bajo una perspectiva
"denegar todo", podrá imaginar que hay miles de reglas que ya están
disponibles en la directriz de referencia. En algunas ocasiones los
desarrolladores saben que ciertas reglas se han activado en un sistema
y desactivado en otros. Aunque esto se puede conseguir desarrollando
dos módulos distintos, en el desarrollo de SELinux se optó por
soportar <e>booleanos SELinux</e>.
</p>
<p>
Los booleanos SELinux permiten la aplicación condicional de las reglas,
basándose en los requisitos que imponga el administrador. Puede obtener
un listado de los booleanos soportados mediante <c>getsebool</c>:
</p>
<pre caption="Obteniendo una lista de booleanos soportados y su estado actual">
~# <i>getsebool -a</i>
allow_execheap --> off
allow_execmem --> off
[...]
fcron_crond --> off
global_ssp --> on
[...]
</pre>
<p>
Si necesita conmutar el valor de un booleano, puede usar
<c>togglesebool</c> o <c>setsebool</c> para indicar su valor
explícitamente:
</p>
<pre caption="Conmutando el estado de un booleano">
~# <i>getsebool user_dmesg</i>
user_dmesg --> off
~# <i>togglesebool user_dmesg</i>
user_dmesg: active
<comment>(Ahora, el estado se ha definido a 'activado')</comment>
~# <i>getsebool user_dmesg</i>
user_dmesg --> on
<comment>(Definimos explícitamente el valor a 'desactivado')</comment>
~# <i>setsebool user_dmesg off</i>
</pre>
</body>
</subsection>
<subsection>
<title>Ficheros de directriz y sus localizaciones</title>
<body>
<p>
En Gentoo Hardened, los ficheros de directriz se almacenan en
<path>/usr/share/selinux/strict</path> o en
<path>/usr/share/selinux/targeted</path> (dependiendo de la configuración
de su sistema SELinux). En esta localización encontrará:
</p>
<ul>
<li>
un fichero llamado <path>base.pp</path>, el cual es la base de la
directriz SELinux,
</li>
<li>
uno o más ficheros con la extensión <path>.pp</path>, que son los
módulos de directriz, y
</li>
<li>
un directorio <path>include/</path> que contiene los ficheros
necesarios para los desarrolladores de módulos SELinux para construir
módulos adicionales para este sistema.
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Versiones de la directriz</title>
<body>
<p>
La infraestructura de la directriz de SELinux que se utiliza (esto es,
las capacidades y funcionalidades que ofrece) no está en su primera
versión. Si pudiera ejecutar ahora mismo <c>sestatus</c>, observaría que
estamos usando la versión 24 de la directriz. Cuando se añaden
nuevas funcionalidades o capacidades, se requieren cambios a la estructura
interna de la directriz compilada y se incremente el número de versión.
A continuación se muestra una vista rápida de la historia de las versiones
de la directriz.
</p>
<dl>
<dt>Versión 12</dt>
<dd>"Antigua API" para SELinux, la cual es ahora obsoleta</dd>
<dt>Versión 15</dt>
<dd>"Nueva API" para SELinux, integrada en el núcleo Linux 2.6.0 (hasta
la versión 2.6.5)</dd>
<dt>Versión 16</dt>
<dd>Añadidas extensiones condicionales a la directriz (2.6.5)</dd>
<dt>Versión 17</dt>
<dd>Añadido soporte para IPV6 (2.6.6 - 2.6.7)</dd>
<dt>Versión 18</dt>
<dd>Añadido soporte para zócalos (sockets) de enlace de red con ajuste fino
(2.6.8 - 2.6.11)</dd>
<dt>Versión 19</dt>
<dd>Mejorada la seguridad multinivel (2.6.12 - 2.6.13)</dd>
<dt>Versión 20</dt>
<dd>Optimizaciones en el acceso al tamaño de la tabla de vectores (2.6.14 -
2.6.18)</dd>
<dt>Versión 21</dt>
<dd>Transiciones en rango de clases de objetos (2.6.19 - 2.6.24)</dd>
<dt>Versión 22</dt>
<dd>Capacidades de la directriz (características) (2.6.25)</dd>
<dt>Versión 23</dt>
<dd>Modo permisivo para cada dominio (2.6.26 - 2.6.27)</dd>
<dt>Versión 24</dt>
<dd>Jerarquía explícita (limites de tipos) (2.6.28 - actual)</dd>
</dl>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-using-commands.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-commands.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-commands.xml?rev=1.1&content-type=text/plain
Index: hb-using-commands.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-commands.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>2</version>
<date>2011-04-22</date>
<section>
<title>Información sobre las órdenes en SELinux</title>
<subsection>
<title>Introducción</title>
<body>
<p>
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.
</p>
<p>
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).
</p>
</body>
</subsection>
<subsection>
<title>Obteniendo el estado de SELinux</title>
<body>
<p>
La primera orden de la que hablaremos es <c>sestatus</c>.
</p>
<pre caption="Ejecutar sestatus">
~# <i>sestatus</i>
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: strict
</pre>
<p>
La salida de esta orden indica que SELinux está habilitado y está
trabajando actualmente en modo permisivo (<e>permissive</e>). También
nos indica que el sistema está configurado para correr en modo
estricto (<e>strict</e>) por lo que no existe el dominio unconfined_t.
</p>
</body>
</subsection>
<subsection>
<title>Obteniendo información de los objetos de SELinux</title>
<body>
<p>
En la siguiente tabla se muestra la orden <c>seinfo</c>. Esta orden
le permite consultar la directriz en ejecución definida para todos los
objetos (tipos, roles, atributos, usuarios, booleanos,...).
</p>
<p>
Algunos usos comunes son los siguientes:
</p>
<ul>
<li>
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).
</li>
<li>
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).
</li>
<li>
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.
</li>
</ul>
<p>
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.
</p>
<pre caption="Usar seinfo">
~# <i>seinfo -tcrontab_t</i>
crontab_t
~# <i>seinfo -ruser_r -x</i>
user_r
Dominated Roles:
user_r
Types:
[...]
crontab_t
[...]
~# <i>seinfo -acron_spool_type -x</i>
cron_spool_type
user_cron_spool_t
system_cron_spool_t
</pre>
</body>
</subsection>
<subsection>
<title>Consultando las reglas de directriz de SELinux</title>
<body>
<p>
Una orden que se usa menudo es <c>sesearch</c>. 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).
</p>
<p>
La orden <c>sesearch</c> se usa frecuentemente con un dominio origen
(<c>-s</c>), dominio destino (<c>-t</c>) 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...
</p>
<p>
Por ejemplo, para averiguar qué dominios pueden escribir en los ficheros
que tienen el dominio shadow_t:
</p>
<pre caption="Consultando las reglas de concesión con sesearch">
~# <i>sesearch -t shadow_t -c file -p write -A</i>
Found 8 semantic av rules:
[...]
allow portage_t shadow_t : file { ioctl read write ... };
allow useradd_t shadow_t : file { ioctl read write ... };
...
</pre>
<p>
Observará que en algunas ocasiones los resultados están basados en los
atributos en lugar de los dominios:
</p>
<pre caption="Regla de permisión basada en atributo">
allow portage_t file_type : file { ioctl read write ... };
</pre>
<p>
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:
</p>
<pre caption="Consultando los dominios que tienen privilegios de escritura en fichero en dominios file_type">
~# <i>sesearch -t file_type -c file -p write -A -d</i>
Found 1 semantic av rules:
allow portage_t file_type : file { ioctl read write ... };
</pre>
<p>
Obseve que tenemos una orden sin la opción <c>-d</c> y otra que usa
esta opción. Cuando se indica <c>-d</c>, la búsqueda será realizada de
forma exacta sin resolver los atributos. Cuando no se indica <c>-d</c>,
entonces se resolverá el atributo. En el último ejemplo, el hecho de no
indicar <c>-d</c> 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.
</p>
</body>
</subsection>
<subsection>
<title>Obteniendo información del contexto de seguridad</title>
<body>
<p>
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.
</p>
<p>
Para consultar el contexto de seguridad de un fichero, utilice <c>ls -Z</c>:
</p>
<pre caption="Obtener el contexto de seguridad de un fichero">
~$ <i>ls -Z /etc/make.conf</i>
system_u:object_r:portage_conf_t /etc/make.conf
</pre>
<p>
Para obtener el contexto de seguridad de un proceso, utilice <c>ps -Z</c>:
</p>
<pre caption="Obtener el contexto de seguridad de un proceso">
~# <i>ps -Z $(pidof init)</i>
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:00 init [3]
</pre>
<p>
Para obtener el contexto de seguridad del usuario actual, utilice
<c>id -Z</c>:
</p>
<pre caption="Obtener el contexto de seguridad de un usuario">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
</pre>
</body>
</subsection>
</section>
<section>
<title>Gestionar SELinux</title>
<subsection>
<title>Introducción</title>
<body>
<p>
La gestión de los objetos de SELinux (booleanos, usuarios, puertos,
contextos ...) se realiza en la mayoría de las ocasiones usando
<c>semanage</c>. 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).
</p>
</body>
</subsection>
<subsection>
<title>Booleanos</title>
<body>
<p>
Hemos hablado de los booleanos de SELinux anteriormente en este libro
así como de las órdenes <c>getsebool</c> and <c>setsebool</c>. Con
<c>semanage</c> 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).
</p>
<pre caption="Listar los booleanos de SELinux disponibles">
~# <i>semanage boolean -l</i>
SELinux boolean Description
allow_ptrace -> off allow_ptrace
rsync_export_all_ro -> off rsync_export_all_ro
</pre>
<note>
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.
</note>
<p>
Puede definir el valor de un booleano con <c>setsebool</c> y
<c>semanage</c>:
</p>
<pre caption="Definir el valor de un booleano de SELinux">
~# <i>semanage boolean -m --on -F user_dmesg</i>
</pre>
</body>
</subsection>
<subsection id="users">
<title>Usuarios y cuentas de SELinux</title>
<body>
<p>
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:
</p>
<pre caption="Listar las cuentas de SELinux">
~# <i>semanage login -l</i>
Login Name SELinux User
__default__ user_u
root root
swift staff_u
system_u system_u
</pre>
<p>
El comportamiento por defecto es que los usuarios ingresan en el sistema
como el usuario <e>user_u</e> de SELinux. Si quiere permitir a otro
usuario (digamos <c>ana</c>) que ingrese como <c>staff_u</c>:
</p>
<pre caption="Haciendo que 'ana' ingrese en el sistema como 'staff_u'">
~# <i>semanage login -a -s staff_u ana</i>
</pre>
<p>
Los usuarios de SELinux pueden por tanto configurarse para que pertenezcan
a uno o más roles.
</p>
<pre caption="Listar las asociaciones de cuentas a roles">
~# <i>semanage user -l</i>
SELinux User SELinux Roles
root staff_r sysadm_r
staff_u staff_r sysadm_r
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Gestionando puertos</title>
<body>
<p>
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 <c>semanage port -l</c>.
</p>
<pre caption="Listar los puestos gestionados por SELinux">
~# <i>semanage port -l | grep '22$'</i>
ssh_port_t tcp 22
</pre>
</body>
</subsection>
</section>
<section>
<title>Usar SELinux</title>
<subsection>
<title>Introducción</title>
<body>
<p>
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.
</p>
</body>
</subsection>
<subsection>
<title>Cambiando de roles</title>
<body>
<p>
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.
</p>
<p>
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 <uri link="#users">Usuarios y cuentas de SELinux</uri>).
</p>
<p>
La orden que permite cambiar entre roles es <c>newrole</c>. Su uso es
bastante lógico.
</p>
<pre caption="Usar newrole">
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Introduzca la contraseña del usuario, ¡no la de root!)</comment>
</pre>
<p>
Cuando se realiza una transición de rol, SELinux pedirá que el usuario
vuelva a autenticarse usando su contraseña. Si ha ingresado en el
sistema como un usuario normal y utliza <c>su</c> o <c>sudo</c> para
convertirse en root, entonces <c>newrole</c> le obligará a introducir
la contraseña de ese usuario.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-using-enforcing.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-enforcing.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-enforcing.xml?rev=1.1&content-type=text/plain
Index: hb-using-enforcing.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-enforcing.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>1</version>
<date>2011-03-02</date>
<section>
<title>Cambiar al modo forzado (enforcing)</title>
<subsection>
<title>Introducción</title>
<body>
<p>
El cambio al modo forzado (enforcing) no requiere que todas las directrices
estén completamente operacionales, tampoco requiere que el sistema se inicie
en modo forzado. Puede comenzar poco a poco, habilitando el modo forzado una
vez que su sistema se haya iniciado, y a continuación habilitarlo durante
el inicio (pero con la posibilidad de deshabilitarlo de nuevo cuando algo
vaya mal) y finalmente reconfigurar su núcleo de modo que la no sea posible
deshabilitar SELinux.
</p>
</body>
</subsection>
<subsection>
<title>Iniciar, cambiar de modo</title>
<body>
<p>
Para iniciar su sistema antes de habilitar el modo forzado, simplemente
inicie de la forma en que lo hace normalmente. Entonces, cuando crea que
puede corre su sistema en modo forzado, ejecute <c>setenforce 1</c>.
</p>
<pre caption="Habilitar el modo forzado">
~# <i>setenforce 1</i>
</pre>
<p>
Es prudente asegurarse de que ha iniciado el sistema pero que no ha
ingresado en él salvo con el usuario root. También verifique que la
sesión que está utilizando actualmente (como root) usa el contexto
<c>root:sysadm_r:sysadm_t</c> o el
<c>unconfined_u:unconfined_r:unconfined_t</c> (de lo contrario puede
que no funcione el cambio al modo forzado).
</p>
<p>
Cuando observe que las cosas van muy, pero que muy mal, deshabilite
SELinux usando <c>setenforce 0</c> e intente solventar los fallos.
</p>
</body>
</subsection>
<subsection>
<title>Arrancando en modo forzado (una sola vez)</title>
<body>
<p>
Cuando quiera arrancar en modo forzado, pero no quiere configurar SELinux
(aún) para correr siempre en modo forzado (dicho de otro modo, solo lo
quiere intentar una vez), añada <c>enforcing=1</c> a las opciones de
configuración del gestor de arranque.
</p>
<pre caption="Ejemplo de configuración de GRUB para arrancar en modo forzado">
kernel /vmlinuz root=/dev/md3 rootflags=data=journal <i>enforcing=1</i>
</pre>
</body>
</subsection>
<subsection>
<title>Arrancar en modo forzado</title>
<body>
<p>
Una vez que compruebe que puede (re)iniciar siempre que lo desee en modo
forzado, edite el fichero <path>/etc/selinux/config</path> y cambie
<c>SELINUX=permissive</c> a <c>SELINUX=enforcing</c>.
</p>
</body>
</subsection>
<subsection>
<title>Reconfigurar el núcleo</title>
<body>
<p>
Una vez esté seguro de que su sistema puede permanecer todo el tiempo en
modo forzado, reconfigure su núcleo de modo que SELinux no pueda ser
deshabilitado.
</p>
<pre caption="Reconfigurar el núcleo Linux">
[*] NSA SELinux Support
[ ] NSA SELinux boot parameter
[ ] NSA SELinux runtime disable
<comment># Asegúrese de que la siguiente opción está deshabilitada</comment>
<i>[ ] NSA SELinux Development Support</i>
[ ] NSA SELinux AVC Statistics
(1) NSA SELinux checkreqprot default value
[ ] NSA SELinux maximum supported policy format version
</pre>
</body>
</subsection>
</section>
<section>
<title>Analizando la AVC</title>
<subsection>
<title>Intrusión o no intrusión</title>
<body>
<p>
Una vez que el sistema esté corriendo en modo forzado, el uso que se le
da al fichero de registro <path>/var/log/avc.log</path> cambia. Mientras
que antes se usaba para informarle sobre denegaciones que podían causar
fallos en su sistema, ahora es usado como fuente de información sobre el
comportamiento de las aplicaciones, y en algunas ocasiones, de su
comportamiento errático.
</p>
<p>
Es importante saber leer los registros AVC, ya que en un futuro (cercano)
podría usar los registros AVC para identificar intentos de intrusión
potenciales. Digamos que está corriendo un servidor Web que atiende
peticiones procedentes de Internet y está contenido en su propio dominio
SELinux. De repente, comienza a obtener denegaciones extrañas de ese
dominio SELinux intentando leer ficheros que realmente no debería leer,
o tratando de escribir algo en una localización temporal en la cual
no debe. Esto puede ser un comportamiento completamente esperado, pero
puede tratarse también de un usuario malicioso que está intentando
ejecutar código malicioso en su servidor Web.
</p>
<p>
Puede considerar que el hecho de interpretar los registros AVC lleve mucho
tiempo si está obteniendo muchas denegaciones AVC que son cosméticas (pero
seguras). En primer lugar veremos si nos podemos deshacer de ellas...
</p>
</body>
</subsection>
<subsection>
<title>Ignorando eventos AVC cosméticos</title>
<body>
<p>
Cuando obtenga denegaciones AVC que considera inofensivas para su sistema,
puede crear un módulo de directriz que contenga la regla AVC exacta, pero
que usa la sentencia <e>dontaudit</e> en lugar de <e>allow</e>.
</p>
<p>
Considere la siguiente denegación AVC:
</p>
<pre caption="Ejemplo de denegación AVC inofensiva">
Jan 6 19:49:25 hpl kernel: [10482.016339] type=1400 audit(1294339765.865:1527):
avc: denied { use } for pid=19421 comm="ifconfig" path="/dev/null" dev=tmpfs
ino=1552 scontext=system_u:system_r:ifconfig_t
tcontext=system_u:system_r:wpa_cli_t tclass=fd
</pre>
<p>
La denegación muestra que el proceso <c>ifconfig</c> está intentando usar
un descriptor de fichero en el dominio wpa_cli_t. El descriptor de fichero
destino apunta a <path>/dev/null</path>. Esto normalmente significa que el
proceso <c>ifconfig</c> se ha iniciado desde el dominio wpa_cli_t con
<c>> /dev/null</c> para redirigir su salida al dispositivo
<path>/dev/null</path>. A pesar de que esto se deniega (por lo que la
salida no será redigirida a <path>/dev/null</path>), no tiene ningún
impacto funcional en el sistema ya que, de cualquier forma, la intención
era ignorar la salida.
</p>
<p>
Entonces, ¿Cómo podemos asegurar que esta regla no inunda nuestros
registros AVC?. Bien, necesitamos crear un módulo (al igual que vimos
anteriormente en <uri link="?part=2&chap=3#create_module">
Crear reglas específicas de concesión</uri>):
</p>
<pre caption="Crear un módulo para ignorar estas denegaciones AVC">
~$ <i>cat ignoreavc.te</i>
module ignoreavc 1.0.0;
require {
type ifconfig_t;
type wpa_cli_t;
class fd use;
}
dontaudit ifconfig_t wpa_cli_t:fd { use };
~$ <i>checkmodule -m -o ignoreavc.mod ignoreavc.te</i>
~$ <i>semodule_package -o ignoreavc.pp -m ignoreavc.mod</i>
~$ <i>semodule -i ignoreavc.pp</i>
</pre>
<p>
Una vez se carga el módulo, no debería volver a ver estas denegaciones en
su registro. Sin embargo, si alguna vez cree que está aplicando la
sentencia <e>dontaudit</e> demasiadas veces, siempre puede recargar las
directrices SELinux sin sentencias dontaudit:
</p>
<pre caption="Recargar las directrices SELinux sin dontaudit">
~# <i>semodule -R -D</i>
</pre>
<p>
Si está seguro de querer continuar con las sentencias dontaudit, ejecute el
mismo comando sin la opción <c>-D</c>.
</p>
<p>
Gentoo Hardened utiliza un booleano específico llamado
<c>gentoo_try_dontaudit</c> para mostrar u ocultar las denegaciones que
los desarrolladores creen que son cosméticas. Gracias a este enfoque,
puede, en primer lugar deshabilitar las sentencias dontaudit seleccionadas
por Gentoo antes de mostrarlas todas, las cuales pueden ser bastantes más.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-using-install.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-install.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-install.xml?rev=1.1&content-type=text/plain
Index: hb-using-install.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-install.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>5</version>
<date>2011-04-16</date>
<section>
<title>Instalar Gentoo Hardened</title>
<subsection>
<title>Introducción</title>
<body>
<p>
Instalar Gentoo Hardened con SELinux no requiere acciones extrañas.
Lo que se necesita es instalar Gentoo Linux con el perfil correcto, la
configuración del núcleo correcta y etiquetar algunos sistemas de ficheros.
Recomendamos seriamente usar SELinux junto con otras mejoras que hagan más
robusto nuestro sistema (como PaX / grSecurity).
</p>
<p>
Este capítulo describe los pasos para instalar Gentoo Hardened con SELinux.
Asumimos que tiene un sistema Gentoo Linux ya funcionando que quiere
convertir a Gentoo Hardened con SELinux. Si este no es el caso, puede
igualmente continuar leyendo: puede instalar Gentoo Hardened con SELinux
inmediatamente si toma las decisiones correctas, basadas en la información
contenida en este capítulo, durante el proceso de instalación.
</p>
</body>
</subsection>
<subsection>
<title>Realizar una instalación estándar</title>
<body>
<p>
Instale Gentoo Linux usando las instrucciones del
<uri link="/doc/es/handbook">manual de Gentoo</uri>. Recomendamos usar
los ficheros tarball hardened de stage3 en lugar de los ficheros
estándar. Haga una instalación completa hasta el punto en el que debe
reiniciar su sistema para obtener una instalación base (primitiva) de
Gentoo.
</p>
<note>
Si utiliza XFS, asegúrese de que el tamaño de los nodos-i del sistema
de ficheros XFS es de 512 bytes. Debido a que el valor por defecto es
256, necesitará ejecutar la orden <c>mkfs.xfs</c> con los argumentos
<c>-i size=512</c>, de esta forma: <c>mkfs.xfs -i size=512 /dev/sda3</c>
</note>
</body>
</subsection>
<subsection>
<title>Instalando la extensión (overlay) de desarrollo de Hardened</title>
<body>
<p>
Aunque opcional, le recomendamos que habilite la extensión
<c>hardened-development</c>. El estado de SELinux en Gentoo Hardened
esta todavía bajo un desarrollo muy activo.
</p>
<p>
Instale <c>app-portage/layman</c> y añada la extensión
<c>hardened-development</c>. Esta extensión utiliza un repositorio git,
por lo que deberá instalar igualmente <c>git</c> o ajustar
<c>USE="git"</c> en <path>/etc/make.conf</path>.
Asegúrese de incluir el fichero <path>make.conf</path> de layman en su
fichero <path>make.conf</path>.
</p>
<pre caption="Instalar la extensión hardened-development">
~# <i>emerge layman</i>
~# <i>layman -S</i>
~# <i>layman -a hardened-development</i>
~# <i>nano /etc/make.conf</i>
<comment># Añada la siguiente línea al comienzo de su fichero make.conf</comment>
<i>source /var/lib/layman/make.conf</i>
</pre>
</body>
</subsection>
<subsection>
<title>Cambiando a Python 2</title>
<body>
<p>
Hasta la fecha, las utilidades de gestión de SELinux no son compatibles
con Python 3 por lo que le recomendamos cambiar a Python 2 hasta que los
paquetes sean actualizados y corregidos.
</p>
<pre caption="Cambiando a python 2">
~# <i>eselect python list</i>
Available Python interpreters:
[1] python2.7
[2] python3.1 *
~# <i>eselect python set 1</i>
~# <i>source /etc/profile</i>
</pre>
</body>
</subsection>
<subsection>
<title>Opcional: Ajustando del contexto /tmp</title>
<body>
<p>
Si la su directorio <path>/tmp</path> está en un sistema de ficheros
tmpfs montado, entonces necesitará indicarle al núcleo que el
contexto raíz de esta localización es <c>tmp_t</c> en lugar de
<c>tmpfs_t</c>. Muchos objetos en la directriz de SELinux (incluyendo
algunas directrices al nivel de servidor) asumen que <path>/tmp</path>
es <c>tmp_t</c>.
</p>
<p>
Para configurar el montaje de <path>/tmp</path>, edite su fichero
<path>/etc/fstab</path>:
</p>
<pre caption="Actualizar /etc/fstab para /tmp">
tmpfs /tmp tmpfs defaults,noexec,nosuid<i>,rootcontext=system_u:object_r:tmp_t</i> 0 0
</pre>
</body>
</subsection>
<subsection>
<title>Habilitando paquetes ~Arch</title>
<body>
<p>
Los paquetes estables actuales relacionados con SELinux no están preparados
para ser usados (o incluso están rotos) por lo que recomendamos seriamente
habilitar los paquetes ~arch para SELinux. Añada los siguientes ajustes
al fichero adecuado (por ejemplo
<path>/etc/portage/package.accept_keywords/selinux</path>):
</p>
<pre caption="Paquetes SELinux ~arch">
sys-libs/libselinux
sys-apps/policycoreutils
sys-libs/libsemanage
sys-libs/libsepol
app-admin/setools
dev-python/sepolgen
sys-apps/checkpolicy
sec-policy/*
=sys-process/vixie-cron-4.1-r11
</pre>
</body>
</subsection>
<subsection>
<title>Cambie el perfil de Gentoo</title>
<body>
<p>
Ahora que tiene una instalación de Gentoo Linux funcionando, cambie el
perfil de Gento al perfil SELinux hardened adecuado (por ejemplo,
<path>selinux/v2refpolicy/amd64/hardened</path>).
</p>
<pre caption="Cambiar el perfil de Gentoo">
~# <i>eselect profile list</i>
Available profile symlink targets:
[1] default/linux/amd64/10.0
[2] default/linux/amd64/10.0/desktop
[3] default/linux/amd64/10.0/desktop/gnome
[4] default/linux/amd64/10.0/desktop/kde
[5] default/linux/amd64/10.0/developer
[6] default/linux/amd64/10.0/no-multilib
[7] default/linux/amd64/10.0/server *
[8] hardened/linux/amd64
[9] hardened/linux/amd64/no-multilib
[10] selinux/2007.0/amd64
[11] selinux/2007.0/amd64/hardened
[12] selinux/v2refpolicy/amd64
[13] selinux/v2refpolicy/amd64/desktop
[14] selinux/v2refpolicy/amd64/developer
[15] selinux/v2refpolicy/amd64/hardened
[16] selinux/v2refpolicy/amd64/server
~# <i>eselect profile set 15</i>
</pre>
<note>
A partir del momento en que cambie su perfil, Portage le advertirá después
de cada instalación que "No pudo ajustar las etiquetas de seguridad de
SELinux". Esto es lo esperado, ya que las herramientas y capacidades que
requiere Portage para ajustar las etiquetas de seguridad todavía no están
disponibles. Esta advertencia desaparecerá en el momento en que se complete
la instalación de SELinux.
</note>
<p>
Edite su fichero <path>/etc/make.conf</path> y ajuste
<c>FEATURES="-loadpolicy"</c>. El perfil actual de SELinux habilita la
característica loadpolicy, sin embargo esta característica ya no está
soportada por lo que puede ser ignorada de forma segura.
</p>
<p>
No actualice su sistema aún. Necesitaremos instalar un par de paquetes
en las próximas dos secciones en un orden en particular para el que
Portage no está preparado.
</p>
</body>
</subsection>
<subsection>
<title>Cambios manuales en el sistema</title>
<body>
<warn>
La mayoría, o todos los cambios que se comentan a continuación se
resolverán automáticamente en los paquetes en cuanto sea posible. Estos
cambios, sin embargo, tienen un impacto más allá de las instalaciones
de Gentoo Hardened. Por lo tanto, estos cambios serán incorporados a un
ritmo más bajo que las actualizaciones específicas de SELinux.
Actualmente, es suficiente con realizar la corrección manual de estas
situaciones (además se trata de una operación que se realiza una única
vez).
</warn>
<p>
Los siguientes cambios <e>pueden</e> ser necesarios en su sistema dependiendo
de las configuraciones o herramientas implicadas.
</p>
<ul>
<li>
Si utiliza LVM para uno o más de sus sistemas de ficheros, necesitará
editar <path>/lib/rcscripts/addons/lvm-start.sh</path>
(o <path>/lib64/..</path>) y <path>lvm-stop.sh</path> y ajustar la
la configuración de la localización de <path>/dev/.lvm</path> a
<path>/etc/lvm/lock</path>. A continuación, cree el directorio
<path>/etc/lvm/lock</path>.
</li>
<li>
Compruebe si tiene los ficheros <path>*.old</path> en <path>/bin</path>.
Si es así, puede eliminarlos o hacer una copia de los mismos de forma
que tengan su propio contexto de seguridad. Los ficheros
<path>.old</path> son enlaces duros que pueden interferir con el
etiquetado de ficheros. Por ejemplo, puuede hacer
<c>cp /bin/hostname /bin/hostname.old</c>.
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Instalar un núcleo SELinux</title>
<body>
<p>
Aunque los núcleos Linux por defecto ofrecen soporte SELinux, recomendamos
el uso del paquete <path>sys-kernel/hardened-sources</path>.
</p>
<pre caption="Instalar hardened-sources">
<comment>(Desde luego, debe hacer esto si no lo ha instalado previamente)</comment>
~# <i>emerge hardened-sources</i>
</pre>
<p>
A continuación, reconfigure su núcleo con los ajustes apropiados de
seguridad. Esto incluye (pero no está limitado a):
</p>
<ul>
<li>
Soporte de los atributos extendidos en los distintos sistemas de
ficheros
</li>
<li>Soporte de la auditoría de llamadas al sistema</li>
<li>Soporte de SELinux</li>
</ul>
<p>
Debajo puede encontrar una lista rápida de los ajustes recomendados.
</p>
<pre caption="Ajustes recomendados para la configuración del núcleo Linux">
<comment>En "General setup"</comment>
[*] Prompt for development and/or incomplete code/drivers
[*] Auditing support
[*] Enable system-call auditing support
<comment>En "File systems"</comment>
<comment>(Para cada sistema de ficheros que utilice, asegúrese de que el soporte de atributos extendidos está habilitado)</comment>
<*> Second extended fs support
[*] Ext2 extended attributes
[ ] Ext2 POSIX Access Control Lists
[*] Ext2 Security Labels
[ ] Ext2 execute in place support
<*> Ext3 journalling file system support
[ ] Default to 'data=ordered' in ext3
[*] Ext3 extended attributes
[ ] Ext3 POSIX Access Control Lists
[*] Ext3 Security Labels
<*> The Extended 4 (ext4) filesystem
[*] Ext4 extended attributes
[ ] Ext4 POSIX Access Control Lists
[*] Ext4 Security Labels
<*> JFS filesystem support
[ ] JFS POSIX Access Control Lists
[*] JFS Security Labels
[ ] JFS debugging
[ ] JFS statistics
<*> XFS filesystem support
[ ] XFS Quota support
[ ] XFS POSIX ACL support
[ ] XFS Realtime subvolume support (EXPERIMENTAL)
[ ] XFS Debugging Support
<*> Btrfs filesystem (EXPERIMENTAL)
[ ] Btrfs POSIX Access Control Lists
<comment>En "Security options"</comment>
[*] Enable different security models
[*] Socket and Networking Security Hooks
[*] NSA SELinux Support
[ ] NSA SELinux boot parameter
[ ] NSA SELinux runtime disable
[*] NSA SELinux Development Support
[ ] NSA SELinux AVC Statistics
(1) NSA SELinux checkreqprot default value
[ ] NSA SELinux maximum supported policy format version
Default security module (SELinux) --->
</pre>
<p>
Recomendamos igualmente el uso de PaX. Se puede encontrar más información
sobre PaX en el contexto Gentoo Hardened en
<uri link="/proj/es/hardened/pax-quickstart.xml">Guía de inicio rápido
para usar PaX con Gentoo Hardened</uri>.
</p>
<p>
Construya e instale el nuevo núcleo Linux y sus módulos.
</p>
</body>
</subsection>
<subsection>
<title>Actualice fstab</title>
<body>
<p>
A continuación, edite <path>/etc/fstab</path> y añada la siguiente línea:
</p>
<pre caption="Habilitar el sistema de ficheros selinux">
none /selinux selinuxfs defaults 0 0
</pre>
<p>
Cree igualmente el punto de montaje <path>/selinux</path>:
</p>
<pre caption="Crear el punto de montaje /selinux">
~# <i>mkdir /selinux</i>
</pre>
</body>
</subsection>
<subsection>
<title>Reinicie</title>
<body>
<p>
Una vez realizados los cambios mencionados arriba, reinicie su sistema.
Asegúrese de que ahora está corriendo un núcleo Linux kernel con SELinux
habilitado (el sistema de ficheros <path>/selinux</path> deberá estar
montado). No se preocupe, todavía no está activado SELinux.
</p>
</body>
</subsection>
</section>
<section>
<title>Configure SELinux</title>
<subsection>
<title>Introducción</title>
<body>
<p>
Ahora necesitaremos configurar SELinux, para ello, deberemos instalar las
utilidades apropiadas, etiquetar nuestro sistema de ficheros y configurar
la directriz.
</p>
</body>
</subsection>
<subsection>
<title>Instalar directrices y utilidades</title>
<body>
<p>
En primer lugar, instale los paquetes <path>sys-apps/checkpolicy</path> y
<path>sys-apps/policycoreutils</path>. Aunque éstos deben ser instalados
debido a las dependencias con los paquetes de directriz SELinux,
necesitaremos instalarlos en primer lugar, de aquí la opción <c>-1</c>.
</p>
<pre caption="Instalar la directriz y utlidades principales de SELinux">
~# <i>emerge -1 checkpolicy policycoreutils</i>
</pre>
<p>
Ahora deberá instalar el paquete de directriz de SELinux
(<path>sec-policy/selinux-base-policy</path>). Este paquete contiene la
directriz base de SELinux. Ya que Portage intentará etiquetar y recargar
las directrices (debido a la instalación de
<path>sys-apps/policycoreutils</path>), necesitaremos desactivar
temporalmente el soporte de SELinux (ya que Portage no podrá etiquetar
nada si todavía no lo comprende).
</p>
<pre caption="Instalar los paquetes de directriz de SELinux">
~# <i>FEATURES="-selinux" emerge selinux-base-policy</i>
</pre>
<p>
A continuación, reconstruya aquellos paquetes afectados por el cambio
de perfil que hicimos previamente usando una actualización estándar de
"world" que tendrá en cuenta los cambios en los ajustes USE (ya que
el nuevo perfil cambiará muchos ajustes USE por defecto, incluyendo el
ajuste USE <c>selinux</c>).
</p>
<pre caption="Actualice su sistema Gentoo Linux">
~# <i>emerge -uDN world</i>
</pre>
<p>
Ahora, instale las herramientas adicionales de SELinux que necesitará en
el futuro para depurar o ayudarle con su instalación de SELinux. Estos
paquetes son opcionales, pero recomendamos su instalación.
</p>
<pre caption="Instalar paquetes adicionales de SELinux">
~# <i>emerge setools sepolgen checkpolicy</i>
</pre>
<p>
Para terminar, instale los módulos de directrices para aquellas utilidades
para las que crea que va a necesitar esas directrices. En un futuro no
muy lejano, esto será realizado automáticamente (los paquetes tendrán una
dependencia opcional producida por el ajustes USE selinux), pero hasta ese
momento, necesitará instalarlos manualmente.
</p>
<pre caption="Instalar los módulos de SELinux">
~# <i>eix selinux-</i>
[...]
<comment>(Seleccione los módulos que desea instalar)</comment>
~# <i>emerge selinux-screen selinux-gnupg selinux-sudo selinux-ntp selinux-networkmanager ...</i>
</pre>
</body>
</subsection>
<subsection>
<title>Configure la directriz de SELinux</title>
<body>
<p>
Dentro de <path>/etc/selinux/config</path> puede definir cómo se va a
configurar SELinux en el momento en que se inicie el sistema.
</p>
<pre caption="Editar el fichero /etc/selinux/config">
# This file controls the state of SELinux on the system on boot.
# SELINUX can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=<i>permissive</i>
# SELINUXTYPE can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=<i>strict</i>
</pre>
<p>
En este fichero de configuración se pueden definir dos variables:
</p>
<ul>
<li>
<c>SELINUX</c> indica cómo se debe comportar SELinux:
<ul>
<li>
<c>enforcing</c> (forzado) habilitará el cumplimiento de las
directrices. Esto es precisamente lo que queremos, sin embargo,
probablemente quiera comenzar con el modo permisivo
(<c>permissive</c>).
</li>
<li>
<c>permissive</c> (permisivo) habilitará las directrices pero no
obligará a su cumplimiento. Se le notificará cualquier violación
de las directrices pero no se denegará. Debe comenzar con esta
situación de forma que no tenga impacto en su sistema hasta que
no esté más familiarizado con SELinux. Deberá validar las
advertencias recibidas para ver si puede cambiar al modo
forzado (<c>enforcing</c>) o no.
</li>
<li>
<c>disabled</c> (deshabilitado) desactivará completamente las
directrices. Debido a que en esta situación no se muestran las
violaciones de las directrices, no es la situación recomendada.
</li>
</ul>
</li>
<li>
<c>SELINUXTYPE</c> indica si un dominio "no confinado" se cargará o
no. En Gentoo Hardened se recomienda el uso de <c>strict</c> para
los servidores y <c>targeted</c> para los equipos de sobremesa.
</li>
</ul>
<p>
La diferencia entre <c>strict</c> y <c>targeted</c> se basa en el
dominio <e>no confinado</e>. Cuando se cargan los procesos en su sistema
que no son específicamente confinados en un módulo de directrices, serán
parte del dominio unconfined_t, cuyo propósito es permitir las actividades
por defecto (en lugar de denegarlas por defecto). Como resultado, los
procesos que corren dentro del dominio unconfined_t no tienen restricciones
salvo aquéllas forzadas por las seguridad estándar de Linux. Aunque se
considera más seguro trabajar sin el dominio unconfined_t, será más
complicado para el administrador asegurarse de que el sistema funciona
correctamente ya que no hay módulos de directrices para todas y cada una
de las aplicaciones que están "por ahí fuera".
</p>
<p>
Cuando decida si va a usar <c>strict</c> o <c>targeted</c>, guárdelo en su
fichero <path>/etc/make.conf</path>. De esta forma, Portage instalará
únicamente los módulos de directrices para ese tipo de SELinux en lugar
de instalar los dos.
</p>
<pre caption="Ajustar el tipo de directriz en make.conf">
~# <i>nano /etc/make.conf</i>
POLICY_TYPES="<i>strict</i>"
</pre>
</body>
</subsection>
<subsection>
<title>Etiquete el sistema de ficheros</title>
<body>
<impo>
Repita estos pasos cada vez que haya reiniciado desde un núcleo que no
tenga SELinux habilitado a un núcleo que sí lo tenga, ya que ejecutar
un núcleo con SELinux deshabilitado no actualizará los atributos de los
ficheros que se creen o manipulen en las actividades diarias en su
sistema.
</impo>
<p>
En primer lugar, reetiquete sus dispositivos. Esto aplicará los contextos
de seguridad (etiquetas) en los ficheros de dispositivo.
</p>
<pre caption="Reetiquetar la estrucura /dev">
~# <i>mkdir /mnt/gentoo</i>
~# <i>mount -o bind / /mnt/gentoo</i>
<comment>(Sustituya "strict" en la orden de abajo por "targeted" si ésta es su elección para SELINUXTYPE)</comment>
~# <i>setfiles -r /mnt/gentoo /etc/selinux/strict/contexts/files/file_contexts /mnt/gentoo/dev</i>
~# <i>umount /mnt/gentoo</i>
</pre>
<p>
A continuación, si tiene un fichero de intercambio en lugar de una partición,
etiquételo de la forma adecuada:
</p>
<pre caption="Etiquetar el fichero de intercambio">
~# <i>semanage fcontext -a -t swapfile_t "/swapfile"</i>
~# <i>restorecon /swapfile</i>
</pre>
<p>
Ahora reetiquete completamente su sistema de ficheros. La orden de abajo
aplicará el contexto de seguridad adecuado a los ficheros de su sistema
de ficheros basándose en la información de contexto de seguridad que
ofrecen los módulos de directrices de SELinux instalados.
</p>
<pre caption="Reetiquetar completamente el sistema de ficheros">
~# <i>rlpkg -a -r</i>
</pre>
<p>
Si alguna vez tiene que instalar una directriz de SELinux para un paquete
después de haberlo instalado, necesitará ejecutar <c>rlpkg</c> para ese
paquete de forma que tenga la certeza de que los contextos de seguridad
para los ficheros del paquete son ajustados adecuadamente. Por ejemplo,
si ha instalado <path>sec-policy/selinux-screen</path> después de
darse cuenta de que tiene instalado <c>screen</c> en su sistema:
</p>
<pre caption="Etiquetando de nuevo los ficheros de un único paquete">
<comment>(Asegúrese de que no tiene sesiones de screen corriendo ya que los contextos de seguridad no serán adaptados)</comment>
~# <i>rlpkg -t screen</i>
</pre>
</body>
</subsection>
<subsection>
<title>Reinicie</title>
<body>
<p>
Reinicie su sistema. Ingrese en el mismo y si ha instalado Gentoo usando
los fuentes hardened (como hemos recomendado), habilite el booleano SSP de
SELinux:
</p>
<pre caption="Habilitar el booleano global_ssp">
~# <i>setsebool -P global_ssp on</i>
</pre>
<p>
Cuando haya terminado, disfrute de su trabajo. Acaba de dar sus primeros
pasos por el mundo SELinux.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-using-permissive.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-permissive.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-permissive.xml?rev=1.1&content-type=text/plain
Index: hb-using-permissive.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-permissive.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>4</version>
<date>2011-04-22</date>
<section>
<title>Llevar un registro de las denegaciones</title>
<subsection>
<title>Introducción</title>
<body>
<p>
Desde el momento en que comience a utilizar SELinux en modo permisivo,
SELinux empezará a llevar un registro de todas las denegaciones usando
el registro del sistema. Basándose en esta información, el administrador
puede y debe:
</p>
<ul>
<li>
ver si faltan algunos dominios (por ejemplo, las órdenes se están
ejecutando dentro de un dominio más estándar aunque se esperaba que
se ejecutara dentro de uno más específico) en este caso, se podrá
echar un vistazo al módulo de directriz de SELinux para introducir el
dominio específico.
</li>
<li>
ver si algunos ficheros tienen un contexto de seguridad erróneo en
cuyo caso se puede restaurar su contexto o definirlo de nuevo.
</li>
<li>
ver si algunas denegaciones que no se esperan, se realizan, en cuyo
caso se deberá averiguar porqué se realizan esas denegaciones y cual
era la intención de la directriz original (un primer ejemplo podría ser
un sitio web alojado en un lugar inapropiado en el sistema de ficheros).
</li>
</ul>
<p>
Desde luego, se pueden estudiar otros aspectos cuando se analizan los
mensajes de denegación, sin embargo, los mencionados arriba son los más
comunes.
</p>
</body>
</subsection>
<subsection>
<title>Configurar el registro del sistema</title>
<body>
<p>
Antes de empezar la investigación de las denegaciones, comenzaremos
configurando el registro del sistema para registrar estas denegaciones
en su propio fichero de registro. Si está corriendo syslog-ng con un
perfil Gentoo Hardened, esto ya está configurado para registrar las
denegaciones en <path>/var/log/avc.log</path>:
</p>
<pre caption="Configuración de syslog-ng">
destination avc { file("/var/log/avc.log"); };
[...]
filter f_avc { message(".*avc: .*"); };
filter f_audit { message("^(\\[.*\..*] |)audit.*") and not message(".*avc: .*"); };
[...]
log { source(kernsrc); filter(f_avc); destination(avc); };
</pre>
<p>
Si usa un paquete de registro diferente, tendrá que configurarlo para
que filtre los eventos de auditoría del núcleo. A lo largo del resto del
documento, asumiremos que las denegaciones se registran en
<path>/var/log/avc.log</path>.
</p>
</body>
</subsection>
<subsection>
<title>¿Qué es AVC?</title>
<body>
<p>
Previamente mostramos algunas reglas de permisión de directriz de SELinux,
lo que realmente estábamos mirando era una regla de
<e>vector de acceso</e>. Por ejemplo:
</p>
<pre caption="Ejemplo de regla de vector de acceso">
allow sysadm_t portage_t : process transition ;
</pre>
<p>
Hasta ahora únicamente hemos buscado por permisos de <e>concesión</e>, sin
embargo SELinux soporta otros:
</p>
<ul>
<li>
<e>auditallow</e> permitirá que pueda ocurrir una actividad, pero
la registrará igualmente (con un mensaje "concedido" (granted) en lugar
de "denegado" (denied)).
</li>
<li>
<e>dontaudit</e> permitirá que pueda ocurrir una actividad, sin embargo
no registrará esta situación. Esto es particularmente útil cuando
el registro de la actividad no se necesite, evitando llenar el fichero
<path>avc.log</path>.
</li>
</ul>
<p>
Para mejorar la eficiencia del forzado de la directriz, SELinux utiliza
una caché para estos vectores de acceso: la <e>Caché de Vectores de
Acceso</e> o <e>AVC</e>. Cada vez que se solicita un acceso que no está
en caché, se carga en primer lugar en la caché desde la cual se realiza
su concesión o denegación. De ahí que los mensajes que se registran en
el fichero <path>avc.log</path> contengan la cadena "avc".
</p>
</body>
</subsection>
<subsection id="avclog">
<title>Mirar el registro AVC</title>
<body>
<p>
Durante las operaciones regulares del sistema, puede hacer un seguimiento
de las denegaciones usando una simple sesión de <c>tail</c>:
</p>
<pre caption="Echar un vistazo a los registros avc">
~# <i>tail -f /var/log/avc.log</i>
Jan 1 09:56:59 hpl kernel: [ 2232.354810] type=1400 audit(1293872219.247:156):
avc: denied { setattr } for pid=7419 comm="gorg" name="selinux-handbook.xml" dev=dm-3 ino=159061
scontext=staff_u:staff_r:staff_t tcontext=staff_u:object_r:var_t tclass=file
Jan 1 10:08:52 hpl kernel: [ 2944.664577] type=1400 audit(1293872932.907:157):
avc: denied { use } for pid=9917 comm="ifconfig" path="/dev/null" dev=tmpfs ino=1546
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:wpa_cli_t tclass=fd
Jan 1 10:08:53 hpl kernel: [ 2945.504956] type=1400 audit(1293872933.749:158):
avc: denied { create } for pid=10016 comm="logger"
scontext=system_u:system_r:wpa_cli_t tcontext=system_u:system_r:wpa_cli_t tclass=unix_stream_socket
</pre>
<p>
Pero, ¿Cómo interpretamos estos mensajes?. Bien, echemos un vistazo más
detallado a la primera denegación en este ejemplo.
</p>
<pre caption="Mensaje de denegación ejemplo">
<comment>[ Datos estándares del mensaje de registro como fecha, hora, nombre del equipo,... ]</comment>
Jan 1 09:56:59 hpl kernel: [ 2232.354810] type=1400
<comment>[ Se trata de un mensaje de auditoría que indica una denegación de la llamada de sistema setattr ]</comment>
audit(1293872219.247:156): avc: denied { setattr }
<comment>[ El proceso que lo ha causado tiene el identificador (PID) 7419 y se llama "gorg" ]</comment>
for pid=7419 comm="gorg"
<comment>[ El destino de la llamada al sistema es un fichero denominado "selinux-handbook.xml" en el dispositivo dm-3 device; el fichero está en el i-nodo 159061 ]</comment>
name="selinux-handbook.xml" dev=dm-3 ino=159061
<comment>[ Los contextos de seguridad origen y destino y la clase del destino (en este caso es un fichero) ]</comment>
scontext=staff_u:staff_r:staff_t tcontext=staff_u:object_r:var_t tclass=file
</pre>
<p>
Una entrada similar se halla el la última línea del ejemplo.
</p>
<pre caption="Otro ejemplo de mensaje de denegación">
Jan 1 10:08:53 hpl kernel: [ 2945.504956] type=1400 audit(1293872933.749:158):
avc: denied { create } for pid=10016 comm="logger"
scontext=system_u:system_r:wpa_cli_t tcontext=system_u:system_r:wpa_cli_t tclass=unix_stream_socket
</pre>
<p>
En este caso en particular, el proceso que lo ha provocado es <c>logger</c>
(con PID 10016) que está tratando de crear un zócalo de flujo (stream socket)
de Unix (mira la información <e>tclass</e>).
</p>
<p>
Observe sin embargo que no todos los mensajes AVC implican una denegación.
Algunos accesos registrados por la caché de vectores de acceso son
concesiones pero que tienen una sentencia <e>auditallow</e> explícita de
forma que se puedan seguir en los registros.
</p>
</body>
</subsection>
</section>
<section>
<title>Analizando las denegaciones</title>
<subsection>
<title>Una configuración estándar puede que no funcione</title>
<body>
<p>
Si le ha echado un vistazo a sus denegaciones, probablemente pensará:
"Si voy a cambiar al modo forzado (enforcing), mi sistema no funcionará
adecuadamente" y puede que esté en lo cierto. En este punto Gentoo
Hardened está constantemente actualizando las directrices de SELinux
para tener un sistema en funcionamiento aunque todavía no hemos llegado
a eso. Por esta razón es muy importante saber analizar las denegaciones
(y tomar las acciones correctivas adecuadas).
</p>
<p>
Ahora es sencillo describir cuál es la mejor opción cuando encuentre una
denegación que no debería aparecer. Sin embargo, se han de aplicar algunas
reglas base.
</p>
<ul>
<li>
Verificar si la denegación es cosmética o no. Intente centrarse en las
denegaciones de las que está <e>seguro</e> no son cosméticas y
resultarán en un mal funcionamiento de su sistema (o de esa orden en
particular) si no se toma ninguna acción correctiva.
</li>
<li>
Si encuentra una denegación en la que el contexto de seguridad es
genérico (como <e>sysadm_t</e> o <e>staff_t</e> o <e>user_t</e>),
intente averiguar si existen módulos de directriz de SELinux específicos
para el recurso en cuestión. En el ejemplo anterior del proceso
<c>gorg</c>, definitivamente necesitamos comprobar is no hay ninguna
directriz de SELinux del tipo selinux-gorg. Observe que incluso si
no hay ninguna, no significa que no debiera haberla ;-)
</li>
<li>
Si el destino de la denegación es un fichero, verifique si su contexto
de seguridad es correcto o si tiene que dar un contexto diferente.
También es posible que el proceso esté intentando trabajar en la ruta
incorrecta. A veces, un simple cambio en la configuración del proceso
es suficiente para hacerlo funcionar de forma correcta bajo su
directriz SELinux.
</li>
</ul>
<p>
Mientras se creaban las directrices, los desarrolladores de Gentoo Hardened
intentaron ocultar las denegaciones que pensaban eran cosméticas. Esto se
puede cambiar usando el boolean de SELinux <c>gentoo_try_dontaudit</c>:
</p>
<pre caption="Obtener el valor actual y definir el valor del booleano de Gentoo gentoo_try_dontaudit">
~# <i>getsebool gentoo_try_dontaudit</i>
gentoo_try_dontaudit --> off
~# <i>setsebool -P gentoo_try_dontaudit on</i>
</pre>
<p>
Cuando está activado, las denegaciones que se pensaban eran cosméticas se
ocultan en los registros de auditoría. Si su sistema no está funcionando
correctamente y no ve estas denegaciones, es prudente conmutar este
booleano para verificar si la denegación se muestra o no.
</p>
</body>
</subsection>
<subsection>
<title>Instalar módulos adicionales de directriz de SELinux</title>
<body>
<p>
Cuando se encuentra una denegación para la cual se cree que debería
existir un módulo de directriz de SELinux, averigüe qué paquete ofrece
el recurso que ha causado la denegación y verifique si Gentoo ofrece una
directriz para ese paquete. Si es así, instálela y vuelva a etiquetar los
ficheros del paquete.
</p>
<pre caption="Buscar paquetes de Gentoo SELinux">
~# <i>tail -f /var/log/avc.log</i>
Jan 1 09:42:37 hpl kernel: [ 1372.708172] type=1400 audit(1293871357.972:76):
avc: denied { search } for pid=6937 comm="screen" name="selinux" dev=dm-0
ino=1053303 scontext=staff_u:staff_r:staff_t
tcontext=staff_u:object_r:user_home_t tclass=dir
~# <i>whereis screen</i>
screen: /usr/bin/screen
~# <i>qfile /usr/bin/screen</i>
app-misc/screen (/usr/bin/screen)
~# <i>eix selinux-screen</i>
* sec-policy/selinux-screen
Available versions: ~2.20090730 ~2.20091215 ~2.20101213
Homepage: http://www.gentoo.org/proj/en/hardened/selinux/
Description: SELinux policy for general applications
~# <i>emerge selinux-screen</i>
[...]
~# <i>rlpkg screen</i>
Relabeling: app-misc/screen-4.0.3
</pre>
<p>
Si cree que debería existir un módulo de directriz de SELinux pero no
encuentra ninguno, entonces puede bien descargar el fichero tarball de
directriz de referencia (que puede encontrar en el directorio
<path>distfiles</path> y se llama <path>refpolicy-2.YYYYMMDD.tar.bz2</path>)
y averiguar si hay módulos disponibles (mire en
<path>refpolicy/policy/modules</path> location), bien puede preguntar en
el canal #gentoo-hardened en irc.freenode.net.
</p>
</body>
</subsection>
<subsection>
<title>Actualizando los contextos de seguridad de los ficheros</title>
<body>
<p>
El caso más común de denegación cuando las directrices necesarias
están en su sitio, es el etiquetado incorrecto de los ficheros o
directorios (en otras palabras, el contexto de seguridad del fichero
o directorio destino no es lo que espera en la directriz). Esto se
puede deber a que el fichero no ha sido etiquetado de nuevo desde
que la directriz fue cargada o porque la etiqueta ha cambiado por algún
motivo (razón 1), también puede deberse a que la ruta del fichero no está
en concordancia con las especificaciones del contexto en el módulo de
SELinux (razón 2).
</p>
<p>
La primera posibilidad (el contexto de seguridad es correcto per no se ha
aplicado) se puede corregir de forma fácil mediante el uso de la orden
<c>restorecon</c>. Puede aplicarla a un solo fichero o hacerlo
recursivamente usando la opción <c>-R</c>.
</p>
<pre caption="Ejecutar restorecon para recuperar un contexto de seguridad">
~# <i>restorecon /etc/make.conf</i>
</pre>
<p>
Si, por contra, la definición del contexto del fichero en la directriz
no se puede aplicar al fichero (o directorio), puede todavía indicarle al
sistema que etiquete ese fichero o directorio de forma adecuada. Por
ejemplo, pongamos que tiene su fichero <path>lvm.conf</path> en el
directorio <path>/etc</path> en lugar del directorio <path>/etc/lvm</path>
como se espera en la directriz, entonces puede etiquetar el fichero de
forma correcta usando <c>semanage</c>. Con <c>semanage</c>, se asigna
un contexto de seguridad correcto que no está relacionado con ningún
módulo. Aunque es un ajuste local, se conserva después de cada reinicio.
</p>
<pre caption="Ajustar el nuevo contexto de un fichero usando semanage">
~# <i>semanage fcontext -a -t lvm_etc_t /etc/lvm.conf</i>
~# <i>restorecon /etc/lvm.conf</i>
</pre>
<p>
Si quiere que esta definición forme parte de un módulo que está escribiendo,
necesitará crear un archivo con la información del contexto de ese fichero
que contendrá la(s) definición(es) de los ficheros cuyo contexto desea
definir. Más adelante en este libro se describe cómo escribir módulos de
directriz en <uri link="?part=2&chap=5">Añadiendo módulos de directriz
de SELinux</uri>.
</p>
</body>
</subsection>
<subsection id="create_module">
<title>Crear reglas específicas de concesión</title>
<body>
<p>
Si no se puede resolver una denegación mediante un módulo de directriz de
SELinux disponible o se realiza una acción correctiva para el fichero o
directorio destino o no se dispone de dicho módulo, entonces, deberá optar
por la creación de su propia directriz. Si su objetivo es permitir un
conjunto específico de reglas (en lugar de escribir un módulo de directriz
de SELinux completamente desarrollado), entonces puede usar la herramienta
<c>audit2allow</c> para generar una directriz basada en los registros
de denegaciones.
</p>
<p>
Con <c>audit2allow</c>, puede transformar un mensaje AVC de denegación en
una definición de módulo de directriz SELinux. Esto puede entonces
compilarse en un módulo de directriz binario y empaquetado finalmente
en un módulo de directriz SELinux que se puede (re)cargar fácilmente.
Se recomienda mantener los registros (originales) AVC que se podrán usar
para construir el módulo de directriz SELinux ya que le permitirán
actualizar continuamente el módulo cuando se produzcan nuevas denegaciones.
</p>
<p>
Por ejemplo, para permitir algunas denegaciones relacionadas con <c>sudo</c>,
puede seguir los siguiente pasos...
</p>
<pre caption="Generar, construir e insertar una directriz SELinux">
<comment>[ Añadimos los mensajes AVC al fichero sudo.raw, de modo que, en el futuro, podamos añadir mensajes de denegación adicionales dentro del mismo fichero que será usado para construir un nuevo módulo de directriz SELinux ]</comment>
~# <i>grep 'comm="sudo"' /var/log/avc.log >> sudo.raw</i>
<comment>[ Generamos una definición de módulo llamada 'fixsudo' basada en las denegaciones AVC que hemos capturado ]</comment>
~# <i>cat sudo.raw | audit2allow -m fixsudo > fixsudo.te</i>
<comment>[ A continuación construimos el módulo SELinux ]</comment>
~# <i>checkmodule -m -o fixsudo.mod fixsudo.te</i>
~# <i>semodule_package -o fixsudo.pp -m fixsudo.mod</i>
</pre>
<p>
El módulo de directriz generado (con la extensión <path>.pp</path>) se puede
ahora cargar dinámicamente en el almacén de directrices de SELinux:
</p>
<pre caption="Cargar el módulo generado">
~# <i>semodule -i fixsudo.pp</i>
</pre>
<p>
La definición del módulo (en nuestro ejemplo se llama
<path>fixsudo.te</path>) se puede modificar a nuestro antojo. Su contenido
está expresado en lenguaje humano en formato ASCII.
</p>
<p>
No todas las denegaciones que se obtienen son fallos en la directriz de
seguridad por defecto. Es muy probable que utilice su sistema de una forma
ligeramente diferente a como fue pensada cuando se diseñó la directriz
por defecto de SELinux para Gentoo Hardened. Sin embargo, si cree
que debe cambiar una directriz en tiempo de ejecución debido a un fallo
en la directriz actual, por favor, informe de este hecho en <uri
link="https://bugs.gentoo.org">Bugzilla</uri> de modo que los
desarrolladores de SELinux le puedan echar un vistazo. Igualmente, no
dude en contactar con los desarrolladores de SELinux para Gentoo Hardened
si tiene dudas.
</p>
<p>
Los desarrolladores no muerden. Se alimentan regularmente por lo que no
lo necesitan.
</p>
</body>
</subsection>
</section>
<section>
<title>Trabajando con SELinux</title>
<subsection>
<title>Carga y descarga de módulos</title>
<body>
<p>
Hemos tratado los módulos SELinux en algunas ocasiones a lo largo de este
libro. Hemos aprendido que, para cargar un módulo, podemos usar
<c>semodule -i modulename.pp</c>. La orden <c>semodule</c> ofrece las
siguientes funciones:
</p>
<ul>
<li>
Usando <c>semodule -i modulename.pp</c> puede (re)instalar un módulo
(o instalar una versión mayor de un módulo dado).
</li>
<li>
Usando <c>semodule -u modulename.pp</c> puede actualizar un módulo
ya instalado a una nueva versión de este módulo.
</li>
<li>
Usando <c>semodule -r modulename.pp</c> puede eliminar un módulo del
almacén de directriz de SELinux. El módulo no sera cargado de nuevo
incluso después de un reinicio.
</li>
<li>
Usando <c>semodule -R</c> puede recargar directrices. Una
característica interesante es que puede añadir la opción <c>-D</c>
la cual <e>deshabilitaŕa</e> las reglas <e>dontaudit</e> de la
directriz. Esto puede ser útil, especialmente más adelante cuando
usemos el modo forzado (enforcing) para averiguar porqué algo falla
incluso cuando no hay denegaciones que lo impidan.
</li>
<li>
Usando <c>semodule -B</c> puede forzar la reconstrucción de la directriz
(lo que conlleva por defecto la recarga de toda la directriz). Entre
otras cosas, esta recarga por defecto leerá los usuarios existentes
y sus directorios home y creará los dominios asociados.
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Listar módulos</title>
<body>
<p>
Mediante la orden <c>semodule -l</c> puede obtener una rápida visión de los
módulos instalados junto con su versión actual. Cuando tenga problemas
con las directrices de SELinux y esté intentado obtener ayuda sobre el
problema, conocer la versión de un módulo en particular será muy importante
para encontrar una solución al problema.
</p>
<pre caption="Listar los módulos instalados">
~# <i>semodule -l</i>
dbus 1.14.0
dnsmasq 1.9.0
hal 1.13.0
[...]
</pre>
</body>
</subsection>
<subsection>
<title>Conmutando roles</title>
<body>
<p>
Cuando se está trabajando con un sistema SELinux system, los usuarios
usarán por defecto la cuenta de SELinux user_u (y así, también usarán el
rol de SELonux user_r), de esta forma, no necesitarán realizar ninguna
conmutación de roles: no hay otros roles a los que puedan cambiar.
</p>
<p>
Las cuentas usadas para realizar tareas de administración normalmente
se usan la cuenta de SELinux staff_u SELinux o tienen su propia cuenta
pero que soporta los roles staff_r y sysadm_r. Estas cuentas deben
comenzar con el rol por defecto staff_r. Aunque todavía restringido,
este rol tiene más posibilidades (con respecto a los dominios destino
soportados a los que se puede cambiar) que el rol user_r role.
</p>
<p>
La principal diferencia, sin embargo, es que estos usuarios también tendrán
que cambiar de rol de vez en cuando. Por ejemplo, si quiere usar Portage
(incluso si solo va a consultar el árbol) necesitará estar en el rol
sysadm_r role. Para cambiar de rol utilice la orden <c>newrole</c>:
</p>
<pre caption="Conmutando roles">
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Introduzca su contraseña personal)</comment>
~$
</pre>
<p>
Usando <c>id -Z</c> podrá verificar que ha cambiado de rol correctamente.
</p>
<p>
Ahora bien, ¿Cómo sabe si necesita cambiar de rol?. Generalmente, obtendrá
un mensaje <e>Permiso denegado</e> en uno o más ficheros:
</p>
<pre caption="Averiguando cuando cambiar de rol">
~$ <i>emerge --info</i>
Permission denied: '/etc/make.conf'
</pre>
<p>
Puede que no sea capaz, dentro de su rol actual, de averiguar si el
cambio de rol es suficiente para obtener acceso de lectura. En su rol
actual, puede que tenga la posibilidad de consultar el contexto de
seguridad actual o comprobar las las reglas AV de SELinux. Sin embargo,
si cambia al rol sysadm_r role y ejecuta las consultas adecuadas, podrá
obtener la información que necesita.
</p>
<pre caption="Verificar el acceso de lectura para el fichero /etc/make.conf">
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
~$ <i>newrole -r sysadm_r</i>
Password: <comment>(Introduzca su contraseña personal)</comment>
~$ <i>id -Z</i>
staff_u:sysadm_r:sysadm_t
~$ <i>ls -Z /etc/make.conf</i>
system_u:object_r:portage_conf_t /etc/make.conf
~$ <i>sesearch -t portage_conf_t -c file -p read -A -d</i>
Found 8 semantic av rules:
allow portage_t portage_conf_t : file { ioctl read getattr lock execute execute_no_trans open } ;
<comment># Este es el que estamos buscando</comment>
allow sysadm_t portage_conf_t : file { ioctl read write ... } ;
allow portage_fetch_t portage_conf_t : file { ioctl read getattr lock open } ;
allow restorecond_t portage_conf_t : file { ioctl read getattr lock relabelfrom relabelto open } ;
allow gcc_config_t portage_conf_t : file { ioctl read getattr lock open } ;
allow portage_sandbox_t portage_conf_t : file { ioctl read getattr lock open } ;
allow rsync_t portage_conf_t : file { ioctl read getattr lock open } ;
allow mount_t portage_conf_t : file { ioctl read getattr lock open } ;
</pre>
<p>
Como puede ver, el dominio sysadm_t (que está asociado al rol sysadm_r)
tiene el acceso de lectura necesario. Por el contrario, no hay ningún
signo de acceso de lectura para el dominio staff_t.
</p>
</body>
</subsection>
<subsection>
<title>Usar etiquetas de fichero</title>
<body>
<p>
Mientras esté usando regularmente el sistema, puede que se encuentre en
situaciones en las que necesite ajustar las etiquetas de un fichero
(contextos de seguridad). Hemos hablado ya del uso de <c>semanage</c> y
<c>restorecon</c> para hacerlo, pero existen otros métodos, cada uno
para unos propósitos específicos...
</p>
<p>
Con <c>chcon</c>, los usuarios (no solo los administradores) pueden
etiquetar de nuevo los ficheros (si tienen los privilegios necesarios
para hacerlo) al tipo que se desee. Como ejemplo, considere los dominios
y reglas para las aplicaciones de Mozilla (como firefox). Por defecto,
este dominio no tiene la capacidad para crear nuevos ficheros en el
directorio home. Sin embargo, se ha creado un dominio específico
(mozilla_home_t) en el cual la aplicación puede crear ficheros. Creando
un directorio (por ejemplo <path>Descargas</path>) y etiquetándolo de
nuevo correctamente, la aplicación podrá crear nuevos ficheros en este
directorio.
</p>
<pre caption="Etiquetar de nuevo un directorio">
~$ <i>ls -Zd ~/Descargas</i>
staff_u:object_r:user_home_t Descargas/
~$ <i>chcon -t mozilla_home_t ~/Descargas</i>
~$ <i>ls -Zd ~/Descargas</i>
staff_u:object_r:mozilla_home_t
</pre>
<p>
Es importante comprender que el reetiquetado es un privilegio específico
que se gestiona mediante las directrices de SELinux (el dominio staff_t
tiene este privilegio en el dominio user_home_t). También, el dominio
destino (mozilla_home_t) todavía es gestionable por el dominio staff_t
(incluyendo el reetiquetado) de forma que la actividad de reetiquetado
no inhabilita los privilegios que staff_t tiene en este directorio. Este
no es siempre el caso, por lo que debe de tener cuidado cuando haga
un reetiquetado.
</p>
<p>
El reetiquetado de ficheros se gestiona mediante los privilegios
relabelfrom y relabelto. Considere las dos reglas hipotéticas siguientes:
</p>
<pre caption="Reglas de reetiquetado">
allow staff_t foo_t : dir { relabelfrom relabelto };
allow staff_t bar_t : dir { relabelto };
</pre>
<p>
En la primera regla, el dominio staff_t domain tiene la capacidad de
reetiquetar los directorios que están actualmente en el dominio foo_t
(relabelfrom) y para reetiquetar directorios hacia el dominio foo_t (si el
dominio fuente tiene definido un privilegio relabelfrom de forma correcta).
En la segunda regla, el dominio staff_t solo puede reetiquetar
directorios hacia el dominio bar_t. Sin embargo, una vez que un directorio
tiene el dominio bar_t, el dominio staff_t no tiene la capacidad
de reetiquetarlo a otro valor (ya que no tiene el privilegio relabelfrom).
</p>
</body>
</subsection>
<subsection>
<title>Etiquetando de nuevo los contenidos de los paquetes de Gentoo</title>
<body>
<p>
En esta última sección, hablaremos del soporte de Gentoo para el
reetiquetado de ficheros. Por defecto, Portage etiqueta de nuevo todos
los ficheros de un paquete cuando lo instala. Esto se gestiona mediante
el uso del ajuste FEATURES="selinux" que se define cuando selecciona
algún perfil de selinux. Un administrador también puede etiquetar de
nuevo el contenido de un paquete usando la orden (específica de Gentoo)
<c>rlpkg</c> (que se instala gracias al paquete policycoreutils):
</p>
<pre caption="Volver a etiquetar los ficheros y directorios de un paquete">
~# <i>rlpkg net-tools</i>
Relabeling: sys-apps/net-tools-1.60_p20090728014017-r1
</pre>
<p>
Esta misma herramienta se puede usar para volver a etiquetar todo el
sistema.
</p>
<pre caption="Volver a etiquetar todo el sistema (de ficheros)">
~# <i>rlpkg -a -r</i>
</pre>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/hb-using-policymodules.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-policymodules.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-policymodules.xml?rev=1.1&content-type=text/plain
Index: hb-using-policymodules.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/hb-using-policymodules.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<sections>
<version>1</version>
<date>2011-03-02</date>
<section>
<title>Escribiendo directrices sencillas</title>
<subsection>
<title>Escribiendo un fichero TE</title>
<body>
<p>
Haremos un resumen de las experiencias previas escribiendo directrices
sencillas. Hemos visto brevemente como trabajar con un fichero
<path>.te</path> y convertirlo a un módulo SELinux cargable. Volvamos
a ello de nuevo con un sencillo ejemplo: permitir execmem al dominio
mozilla_t.
</p>
<p>
Cuando usamos el módulo <path>selinux-mozilla</path> ofrecido por SELinux,
se puede provocar un fallo si se está usando el paquete binario de firefox
de 32 bits (<path>www-client/firefox-bin</path>) y no se permite memexec
(consulte el booleano <c>allow_memexec</c>). Probablemnte encontrará
una denegación AVC indicándole esta situación. Si quiere permitir que
solo mozilla_t pueda ejecutar execmem, puede escribir el siguiente módulo
<path>fixmozilla.te</path>:
</p>
<pre caption="Contenido de fixmozilla.te">
module fixmozilla 1.0.0;
require {
type mozilla_t;
class process execmem;
}
allow mozilla_t self:process { execmem };
</pre>
<p>
Esta sencilla directriz indica que el módulo se llama <e>fixmozilla</e>
y que su versión es la <e>1.0.0</e> (es prudente actualizar este número
de versión cada vez que se actualiza el módulo, de modo que se puede
verificar de rápidamente si la nueva versión se ha cargado o no con
la orden <c>semodule -l</c>). Se requiere el dominio <e>mozilla_t</e>
(si <path>sec-policy/selinux-mozilla</path> no está instalado, fallará
la carga de esta directriz ya que no se puede encontrar el dominio
mozilla_t domain), también se necesita la clase <e>process</e> con la
operación <e>execmem</e>. La directriz propiamente dicha (la sentencia
AVC) permite al dominio mozilla_t domain usar execmem en sus propios
procesos.
</p>
<p>
Para convertir este fichero fuente en una directriz que se pueda cargar,
la convertiremos primero en un fichero <path>.mod</path>:
</p>
<pre caption="Convertir un fichero .te a un fichero .mod">
~$ <i>checkmodule -m -o fixmozilla.mod fixmozilla.te</i>
</pre>
<p>
Con esta orden en particular, creamos un fichero de módulo
(<path>fixmozilla.mod</path>) que no es de base (<c>-m</c>), el cual
contiene las sentencias indicadas en el fichero <path>fixmozilla.te</path>.
Si esta corriendo un sistema MLS/MCS necesitará añadir la opción <c>-M</c>.
</p>
<p>
A continuación empaquetamos este módulo en un módulo SELinux cargable.
</p>
<pre caption="Empaquetar el fichero .mod en un módulo cargable SELinux">
~$ <i>semodule_package -o fixmozilla.pp -m fixmozilla.mod</i>
</pre>
<p>
Este fichero de módulo final (<path>fixmozilla.pp</path>) se puede cargar
en el almacén de directrices de SELinux usando
<c>semodule -i fixmozilla.pp</c>.
</p>
<p>
Usando este método relativamente sencillo, puede crear todas las reglas de
directriz que quiera. Sin embargo, seguramente también quiera añadir
información de etiquetado del fichero...
</p>
</body>
</subsection>
<subsection>
<title>Escribiendo un fichero FC</title>
<body>
<p>
Un fichero FC (<e>Fichero de Contexto</e>) contiene las etiquetas de fichero
(contexto de seguridad) que se deben asignar a algunos ficheros en
particular. Si estructura sus módulos de forma adecuada, probablemente tenga
directrices para algunos programas en particular, e igualmente querrá
etiquetar los ficheros y binarios adecuadamente. Para esto se utilizan los
ficheros <path>.fc</path>.
</p>
<p>
Echemos un vistazo a un ejemplo de fichero .fc el cual contiene los
distintos tipos de definiciones de contexto soportados:
</p>
<pre caption="Ejemplo de fichero .fc">
/var/.* gen_context(system_u:object_r:var_t)
/dev/.*tty[^/]* -c gen_context(system_u:object_r:tty_device_t)
/dev/p[fg][0-3] -b gen_context(system_u:object_r:removable_device_t)
/vmlinuz.* -l gen_context(system_u:object_r:boot_t)
/usr/bin/firefox -- gen_context(system_u:object_r:mozilla_exec_t)
/tmp/\.ICE-unix/.* -s <<none>>
/dev/initctl -p gen_context(system_u:object_r:initctl_t)
/mnt(/[^/]*)? -d gen_context(system_u:object_r:mnt_t)
</pre>
<p>
La primera columna (de cada línea) comienza con una expresión regular para
que concuerde con la ruta del fichero. Esto normalmente es suficiente para
que concuerden la mayoría de ficheros posible. SELinux no soporta algunas
variabes como ROLE, HOME_DIR, HOME_ROOT y USER que son sustituidas por sus
valores correspondientes cuando el fichero de contexto es (re)compilado
(por ejemplo cuando se añaden o eliminan usuarios o se reconstruye la
directriz usando <c>semodule</c>).
</p>
<p>
La segunda columna, si está presente, comienza con un guión seguido del
tipo de fichero: dispositivo de <c>c</c>arácter, dispositivo de
<c>b</c>loque, en<c>l</c>ace simbólico, zócalo (<c>s</c>ocket),
<c>d</c>irectorio, tubería nombrada (named <c>p</c>ipe) o un
fichero regular (<c>-</c>).
</p>
<p>
La última columna indica el contexto de seguridad (etiqueta) que debe
ser asignado a el(los) recurso(s) que concuerda con la expresión regular.
Deberá siempre indicarse los "tres estándar" (usuario, rol y dominio),
sin embargo, puede incluirse también el nivel de seguridad e incluso
la categoría si se usa MLS/MCS o están soportados por el módulo.
</p>
<pre caption="Ejemplo de fichero de contexto con soporte MLS/MCS">
/usr/tmp -d gen_context(system_u:object_r:tmp_t,s0-s15,c0.c255)
</pre>
<p>
Puede escribir su propio fichero FC. Por ejemplo, Gentoo añade la siguiente
definición al paquete <path>sec-policy/selinux-mozilla</path> para dar
soporte al paquete binario de firefox:
</p>
<pre caption="Ejemplo de contenido .fc">
/usr/bin/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/libxul\.so -- gen_context(system_u:object_r:textrel_shlib_t,s0)
/opt/firefox/firefox -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/run-mozilla.sh -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/firefox-bin -- gen_context(system_u:object_r:mozilla_exec_t,s0)
/opt/firefox/plugin-container -- gen_context(system_u:object_r:mozilla_exec_t,s0)
</pre>
<p>
Si quiere añadir este fichero a su directriz, hágalo durante la fase
<c>semodule_package</c>:
</p>
<pre caption="Añadir información de contexto a una directriz">
~$ <i>semodule_package -o fixmozilla.pp -m fixmozilla.mod -f fixmozilla.fc</i>
</pre>
<p>
Una vez que se ha cargado la directriz, puede usar herramientas como
<c>matchpathcon</c>, <c>restorecon</c> y algunas más ya que saben cómo
tratar los ficheros indicados en su fichero de contexto.
</p>
</body>
</subsection>
</section>
<section>
<title>Construyendo un módulo de directriz de referencia</title>
<subsection>
<title>Introducción a la directriz de referencia</title>
<body>
<p>
Anteriormente hemos hablado del hecho de que Gentoo Hardened basa sus
directrices en la directriz de referencia que mantiene Tresys. Esta
directriz de referencia ofrece una funcionalidad importante añadida
durente el desarrollo de los módulos: las interfaces.
</p>
<p>
Al crear una interfaz, realmente se crea una función de algún tipo
que puede ser usada en otros módulos. Estas interfaces permiten a los
desarrolladores generar reglas para interactuar con el dominio de su
módulo sin conocer cuáles son los otros módulos. Por ejemplo, el módulo
de mozilla tiene una definición de interfaz como la siguiente:
</p>
<pre caption="Ejemplo de definición de interfaz">
interface(`mozilla_read_user_home_files',`
gen_require(`
type mozilla_home_t;
')
allow $1 mozilla_home_t:dir list_dir_perms;
allow $1 mozilla_home_t:file read_file_perms;
allow $1 mozilla_home_t:lnk_file read_lnk_file_perms;
userdom_search_user_home_dirs($1)
')
</pre>
<p>
Esta interfaz permite a otros módulos usar la función
<c>mozilla_read_user_home_files</c> si se quiere que sus dominios
puedan (en este caso) leer los ficheros en el dominio
mozilla_home_t domain. Desde luego, se pueden añadir todas las
sentencias dentro de su propia definición, pero entonces necesitarían
que se haya cargado el módulo mozilla, lo que sería una presunción
inapropiada y duplicaría las mismas sentencias de concesión para
cada aplicación. El uso de interfaces hace más fácil el desarrollo
de directrices.
</p>
<p>
También, la directriz de referencia permite el uso de sentencias
<e>optional</e>: un módulo puede llamar a una interfaz en otro
módulo y la directriz no fallará aún en el caso en que el otro
módulo no esté en un sistema de usuario.
</p>
<p>
Por ejemplo, en la directriz evolution:
</p>
<pre caption="Extracto de evolution.te">
optional_policy(`
mozilla_read_user_home_files(evolution_t)
mozilla_domtrans(evolution_t)
')
</pre>
<p>
En este extracto vemos que se llama a la interfaz definida
previamente con el argumento evolution_t (el dominio Evolution) dentro
de una claúsula <c>optional_policy</c>. Como resultado, la construcción
de esta directriz intentará llamar a esta interfaz y la construcción
del módulo no fallará aunque la interfaz no se encuentre (porque el
módulo mozilla no está instalado).
</p>
<p>
El uso de interfaces permite una separación limpia de los distintos
módulos. Dentro de la directriz de referencia se pueden en cuenta
las siguientes cuestiones:
</p>
<ul>
<li>
Dentro de un fichero <path>.te</path>, los únicos dominios que se
permiten mencionar son aquellos definidos en el fichero
<path>.te</path>. Cualquier interacción con otros dominios se debe
realizar en las interfaces ofrecidas por ese dominio.
</li>
<li>
Dentro de un fichero <path>.if</path>, en los que se definen las
interfaces, se usa una sintaxis de tipo XML para documentar cada
interfaz, permitiendo a los desarrolladores leer de forma fácil lo
que se supone debe hacer la interfaz (ya que, honestamente, hay
interfaces mucho más complejas que la que acabamos de ver).
</li>
<li>
Aspectos específicos de la distribución de módulos deben
incluirse en una sentencia <c>ifdef(`distro_gentoo',`...')</c>
(ejemplo para Gentoo). Se soporta esta sentencia en los tres tipos
de fichero (<path>.te</path>, <path>.if</path> y <path>.fc</path>).
</li>
</ul>
</body>
</subsection>
<subsection>
<title>Constriuir el módulo de directriz de referencia</title>
<body>
<p>
Si quiere construir un módulo usando las interfaces de directriz de
referencia, necesitará en primer lugar crear el fichero <path>.te</path>
y, opcionalmente, (y necesario en la mayoría de los casos) los ficheros
<path>.if</path> y <path>.fc</path>. Es prudente comenzar con un conjunto
ejemplo de ficheros para una aplicación similar. Si quiere o necesita
usar interfaces de módulos diferentes, puede encontrarlas en su
sistema dentro de <path>/usr/share/selinux/strict/include</path>.
</p>
<p>
Cuando quiera construir el módulo, copie el fichero
<path>/usr/share/selinux/strict/include/Makefile</path> dentro del
directorio donde almacene su(s) definición(es). Entonces, ejecute
<c>make</c> para construir los módulos de directriz.
</p>
<p>
El resultado debería consistir en uno (o más) módulos de SELinux.
</p>
</body>
</subsection>
</section>
<section>
<title>Ejemplo: Comenzar construyendo la directriz para Skype</title>
<subsection>
<title>Etiquetar</title>
<body>
<p>
Comencemos creando un módulo de directriz de referencia sencilla de
SELinux para la aplicación <c>skype</c>. Esta aplicación es bien
conocida y se usa para realizar charlas de voz y vídeo a través de
Internet. No terminaremos el módulo en este capítulo (ya que este
ejercicio se convertirá en un ciclo repetitivo de pruebas y errores
que no procede comentar en este momento), en lugar de esto mostraremos
un enfoque acerca de como trabajar con estos ejercicios de construcción
de directrices.
</p>
<p>
En primer lugar, nos familiarizaremos con la aplicación.
</p>
<p>
La forma normal de interactuar con <c>skype</c> es desde un punto de
acceso como usuario (no como administrador). Al interactuar con la
aplicación en modo permisivo (o desde un sistema en el que no se ha
habilitado SELinux), comprobamos que crea un directorio
<path>~/.Skype</path> que se utiliza para almacenar su configuración,
historia de las charlas que se han mantenido y algunas cosas más.
</p>
<p>
Sabiendo lo de arriba, echemos un vistazo al contenido del paquete
<path>net-im/skype</path>:
</p>
<pre caption="Contenido del paquete skype">
~$ <i>qlist skype</i>
<comment>(Salida ordenada por claridad)</comment>
/usr/bin/skype
/usr/share/... <comment># No relacionado con la aplicación pero usado por la distribución</comment>
/opt/skype/skype
/opt/skype/sounds/...
/opt/skype/lang/...
/opt/skype/avatars/...
</pre>
<p>
Con esta información, podríamos crear la siguiente definición de contexto
del fichero:
</p>
<pre caption="Ejemplo de fichero de contexto para skype">
/usr/bin/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
/opt/skype/skype -- gen_context(system_u:object_r:skype_exec_t,s0)
HOME_DIR/\.Skype(/.*)? gen_context(system_u:object_r:skype_home_t,s0)
</pre>
<p>
No le daremos a los distintos ficheros de la aplicación skype una etiqueta
específica, son todos ficheros de solo lectura, por lo que pueden
conservar asignada la etiqueta por defecto.
</p>
<p>
Dentro del fichero <path>skype.te</path>, definimos los dominios
necesarios y también utilizamos las primeras interfaces que normalmente
están asociadas a este tipo de dominios (para ver estas razones, puede
leer los fuentes para el módulo apache u otros servicios). Un sencillo
módulo para basar nuestra definición podría ser telepathy...
</p>
<pre caption="Definición inicial del módulo de skype">
policy_module(skype, 1.0.0)
type skype_t;
type skype_exec_t;
application_domain(skype_t, skype_exec_t)
type skype_home_t;
userdom_user_home_content(skype_home_t)
# Allow skype_t to put files in the skype_home_t location(s)
manage_dirs_pattern(skype_t, skype_home_t, skype_home_t)
manage_files_pattern(skype_t, skype_home_t, skype_home_t)
userdom_user_home_dir_filetrans(skype_t, skype_home_t, { dir file })
userdom_search_user_home_dirs(skype_t)
</pre>
<p>
De nuevo, no vamos a explicar las distintas interfaces. Están documentadas
y disponibles en el sistema y existen multitud de ejemplos de uso.
</p>
<p>
Finalmente, vamos a crear una interfaz para permitir a los usuarios
cambiar al dominio skype_t. La idea es añadir
<c>skype_role(role, domain)</c> en la definición <path>.te</path>
del dominio de usuario o dentro de su propia directriz.
</p>
<pre caption="Definir la interfaz skype_role">
interface(`skype_role',`
gen_require(`
type skype_t, skype_exec_t;
')
role $1 types skype_t;
domain_auto_trans($2, skype_exec_t, skype_t)
')
</pre>
<p>
Construya el módulo y cárguelo en el almacén de SELinux. A
continuación cree una directriz sencilla para permitir a los
usuarios (user_r, user_t) acceder a skype:
</p>
<pre caption="Añádir acceso a skype para los usuarios">
~$ <i>cat skypeusers.te</i>
policy_module(skypeusers, 1.0.0)
gen_require(`
type user_t;
role user_r;
type staff_t;
role staff_r;
')
optional_policy(`
skype_role(user_r, user_t)
skype_role(staff_r, staff_t)
')
</pre>
<p>
Construya también este módulo y cárguelo. Un usuario regular de SELinux
debería ahora poder ejecutar skype_exec_t y cambiar al dominio skype_t.
</p>
</body>
</subsection>
<subsection>
<title>Ensayo general</title>
<body>
<p>
Una vez cargada la directriz, haga un ensayo general. Etiquete de nuevo
los ficheros del paquete <path>net-im/skype</path> (y si ha ejecutado
previamente skype, etiquete de nuevo el directorio <path>~/.Skype</path>),
entonces ejecute <c>skype</c> y compruebe tanto la salida de la aplicación
como las denegaciones AVC.
</p>
<p>
Enseguida notamos que el binario (skype) se cuelga y no se puede matar.
En los registros de denegación AVC encontramos las siguientes
denegaciones:
</p>
<pre caption="Denegaciones que se muestran durante la ejecución de skype">
Jan 6 22:01:56 hpl kernel: [18418.420427] type=1400 audit(1294347716.358:2221):
avc: denied { read write } for pid=25540 comm="skype" name="1" dev=devpts
ino=4 scontext=staff_u:staff_r:skype_t tcontext=staff_u:object_r:user_devpts_t
tclass=chr_file
Jan 6 22:01:56 hpl kernel: [18418.420455] type=1400 audit(1294347716.358:2222):
avc: denied { use } for pid=25540 comm="skype" path="/dev/pts/1" dev=devpts
ino=4 scontext=staff_u:staff_r:skype_t tcontext=staff_u:staff_r:staff_t
tclass=fd
Jan 6 22:01:56 hpl kernel: [18418.420563] type=1400 audit(1294347716.358:2225):
avc: denied { sigchld } for pid=6532 comm="bash"
scontext=staff_u:staff_r:skype_t tcontext=staff_u:staff_r:staff_t tclass=process
</pre>
<p>
Observe que el intento se realiza en modo forzado (enforcing), si se
realiza en modo permisivo, se generarían más denegaciones AVC y también es
una forma correcta de crear las reglas necesarias.
</p>
<p>
De estas denegaciones, extraemos que skype intenta usa el pts en el que
se ha ejecutado la orden (observe que esto falla debido a que no lo
permitimos explícitamente) y también falla cuando se le envía una señal
de salida (no se puede enviar una señal sigchld).
</p>
<p>
Mirando las directrices ejemplo que hemos visto, nos damos cuenta de que
tienen interfaces en uso como <c>userdom_use_user_terminals</c> así como
concesiones genéricas como <c>ps_process_pattern</c> (para permitir a los
usuarios ver un proceso y matarlo). Esto es un buen ejemplo de cómo
funciona un sistema MAC de forzado de tipos: por defecto no se asume nada.
</p>
</body>
</subsection>
<subsection>
<title>Siguiente ensayo</title>
<body>
<p>
Después de añadir algunas interfaces para permitir el usao de terminales
de usuario, los descriptores de fichero y también permitir el envío de
señales a los procesos, intentamos ejectuar la aplicación de nuevo.
Obtenemos ahora:
</p>
<pre caption="Salida de la orden skype en ejecución">
~$ <i>skype</i>
Killed
~$ <i>cat /var/log/avc.log</i>
Jan 6 22:27:41 hpl kernel: [19961.313321] type=1400
audit(1294349261.991:9089017): avc: denied { execmem } for pid=27256
comm="skype" scontext=staff_u:staff_r:skype_t tcontext=staff_u:staff_r:skype_t
tclass=process
</pre>
<p>
Por lo menos ahora existe <c>skype</c>. En el registro AVC, vemos que quiere
llamar a execmem (que es algo que no deseamos, pero que también hemos visto
anteriormente con mozilla). De acuerdo, permitámoslo, reconstruyamos los
módulos e intentémoslo otra vez.
</p>
<pre caption="Otra vez la salida de la orden skype">
~$ <i>skype</i>
./skype: error while loading shared libraries: libasound.so.2: cannot open
shared object file: Permission denied
~$ <i>cat /var/log/avc.log</i>
Jan 6 22:33:41 hpl kernel: [20319.960127] type=1400
audit(1294349621.275:9089042): avc: denied { read } for pid=27536
comm="skype" name="libasound.so.2" dev=dm-1 ino=525098
scontext=staff_u:staff_r:skype_t tcontext=system_u:object_r:usr_t
tclass=lnk_file
</pre>
<p>
Bien, necesitamos conceder permisos de lectura a enlaces en el
dominio usr_t domain (y seguramente cargar las librerías desde el
dominio lib_t domain, por lo que necesitamos añadir
<c>files_read_usr_symlinks</c> y <c>libs_use_ld_so</c>, etc.
</p>
</body>
</subsection>
<subsection>
<title>Terminando</title>
<body>
<p>
Después de caer en las cuestiones "no puedo arrancar", observará
que la aplicación necesita asociar y conectarse a puertos, los cuales
están también protegidos por SELinux y se pueden manipular por
varias interfaces. También querrá acceder a su tarjeta de sonido,
cámara Web, etc.
</p>
<p>
Como puede ver leyendo la información de arriba, escribir directrices
de forma correcta no es fácil. Necesita constantemente recordar los que
está concediendo. ¿No estará conceciendo demasiados privilegios?.
¿Está olvidando algo?. También es importante saber que le llevará bastante
rato crear sus primeras directrices, pero con el paso del tiempo lo irá
haciendo mejor. Comenzará a darse cuenta de qué cuestiones que son
estándar necesita conceder y cuáles no.
</p>
<p>
Escribir directrices SELinux no es duro pero es bastante más difícil que
ajustar los permisos estándar de Linux en ficheros y directorios.
Requiere un conocimiento importante del comportamiento de la aplicación y
qué interfaces de directriz de referencia SELinux se conceden cuando las
seleccione.
</p>
<p>
Si alguna vez quiere escribir estas directrices, no dude en leer los
diferentes recursos que hemos preparado al final de este libro.
</p>
</body>
</subsection>
</section>
</sections>
1.1 xml/htdocs/proj/es/hardened/selinux/selinux-handbook.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/selinux-handbook.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux/selinux-handbook.xml?rev=1.1&content-type=text/plain
Index: selinux-handbook.xml
===================================================================
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE book SYSTEM "/dtd/book.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux/selinux-handbook.xml,v 1.1 2011/06/07 18:05:53 nimiux Exp $ -->
<book lang="es">
<title>Manual de SELinux para Gentoo</title>
<author title="Autor">
<mail link="pebenito@gentoo.org">Chris PeBenito</mail>
</author>
<author title="Autor">
<mail link="sven.vermeulen@siphos.be">Sven Vermeulen</mail>
</author>
<author title="Autor">
Chris Richards
</author>
<author title="Traductor">
<mail link="nimiux"/>
</author>
<abstract>
Este es el manual de SELinux para Gentoo.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
<license/>
<version>3.00</version>
<date>2010-12-01</date>
<part>
<title>Introducción a Gentoo/Hardened SELinux</title>
<abstract>
Esta parte cubre SELinux y cómo está posicionado en el proyecto
Gentoo/Hardened.
</abstract>
<chapter>
<title>Mejorando la seguridad en Linux</title>
<abstract>
La seguridad consiste en algo más que habilitar un cierto marco de
trabajo o instalar un núcleo Linux diferente. Es una forma de trabajar
y administrar su sistema Gentoo Linux. Aquí cubrimos algunas buenas
prácticas (genéricas), y entonces trabajamos en el llamado Control de
Acceso Obligatorio (MAC) y cómo SELinux cubre este hueco.
</abstract>
<include href="hb-intro-enhancingsecurity.xml"/>
</chapter>
<chapter>
<title>Conceptos detrás de SELinux</title>
<abstract>
Para poder trabajar correctamente con SELinux, es vital que comprenda
algunos conceptos como dominios, transiciones de dominios y contextos
de ficheros. Sin una comprensión básica de estos aspectos, será dificil
comprender cómo funcionan las directrices de SELinux y cómo actuar en
caso de que las cosas no vayan bien.
</abstract>
<include href="hb-intro-concepts.xml"/>
</chapter>
<chapter>
<title>La directriz (de referencia) de SELinux</title>
<abstract>
Para hacer más eficiente el desarrollo de las directrices de SELinux, se
ha desarrollando una directriz de referencia que se usa en todas las
distribuciones que soportan SELinux. En este capítulo conoceremos
en qué consiste esta directriz de referencia y porqué se desarrolló, así
como el funcionamiento de esta directriz y como progresa su desarrollo.
También cubriremos las cuestiones básicas sobre las directrices de SELinux
en general.
</abstract>
<include href="hb-intro-referencepolicy.xml"/>
</chapter>
<!--
Removed for the time being, not critical.
Moved to next major version of handbook.
<chapter>
<title>SELinux Virtual Machine Support</title>
<abstract>
SELinux support is being actively integrated in libvirt and other
virtualization frameworks to elevate the security of virtualized
environments. Within this chapter we give you a first introduction
on how this is done for libvirt managed environments and what you need to take
into account if you wish to use SELinux within your virtualized environment.
</abstract>
<include href="hb-intro-virtualization.xml"/>
</chapter>
-->
</part>
<part>
<title>Usando SELinux Gentoo/Hardened</title>
<abstract>
Dejando atrás las cuestiones teóricas, abordamos ahora la instalación
de Gentoo/Hardened con un núcleo SELinux así como las herramientas
SELinux tools.
</abstract>
<chapter>
<title>Instalación de Gentoo SELinux / Conversión</title>
<abstract>
Para poner en marcha SELinux en Gentoo/Hardened, necesitará en primer
lugar instalar Gentoo con el perfil Hardened apropiado (o convertir
su perfil actual al perfil Hardened), a continuación puede actualizar
su sistema para convertirlo en uno gestionado por SELinux. En este
capítulo le guiaremos a través de este proceso.
</abstract>
<include href="hb-using-install.xml"/>
</chapter>
<chapter>
<title>Órdenes en SELinux</title>
<abstract>
Antes de que comencemos a usar SELinux, volveremos atrás para aprender
algunas órdenes. Ya que ahora estamos corriendo un sistema con SELinux
habilitado (pero en modo permisivo) podemos familiarizarnos con algunas
ordenes específicas de SELinux.
</abstract>
<include href="hb-using-commands.xml"/>
</chapter>
<chapter>
<title>Corriendo en modo permisivo</title>
<abstract>
Una vez que SELinux está activo, comenzaremos corriendo el sistema en modo
permisivo. En este capítulo le contaremos cómo familiarizarse con SELinux
más aún usando información sobre las órdenes, pero sin interferir con los
controles de acceso estándares (esto es, en modo permisivo).
</abstract>
<include href="hb-using-permissive.xml"/>
</chapter>
<chapter>
<title>Cambiar al modo forzado (enforcing)</title>
<abstract>
Una vez que vea que el sistema puede correr en modo forzado (enforcing),
cambiaremos el sistema para verificar que esto es así. Una vez verficado,
el siguiente paso es (re)iniciar en modo forzado. Finalmente si estamos
seguros de que el modo forzado está funcionando correctamente y que el
sistema está haciendo su trabajo de forma adecuada, modificaremos el
modo forzado de modo que no pueda ser deshabilitado.
</abstract>
<include href="hb-using-enforcing.xml"/>
</chapter>
<chapter>
<title>Añadir módulos de directriz de SELinux</title>
<abstract>
Prácticamente todos los paquetes en los que hay disponibles un módulo de
directriz de SELinux tienen un paquete correspondiente disponible en
Gentoo Hardened. En este capítulo, le ayudaremos a añadir más módulos o
crear los suyos propios para los paquetes para los que no hay directrices
de SELinux disponibles aún.
</abstract>
<include href="hb-using-policymodules.xml"/>
</chapter>
</part>
<part>
<title>Apéndices</title>
<abstract>
Recursos y materiales de referencia adicionales de este libro se mencionan
en este apéndice.
</abstract>
<chapter>
<title>Solucionando problemas con SELinux</title>
<abstract>
Todo lo que realiza el ser humano puede y, de hecho, fallará. En este
capítulo intentaremos seguir la pista de todos los problemas potenciales
que pueden encontrar y cómo resolverlos.
</abstract>
<include href="hb-appendix-troubleshoot.xml"/>
</chapter>
<chapter>
<title>Material de referencia de SELinux</title>
<abstract>
Este manual de Gentoo Hardened SELinux ofrece una primera introducción a
SELinux y cómo se integra en Gentoo Hardened. Sin embargo, muchos
administradores inquietos querrán leer acerca de usos más avanzados de
SELinux (así como retos para realizar su gestión), lo cual sin duda
alguna recomendamos. En este capítulo ofrecemos una lista no muy
exhaustiva.
</abstract>
<include href="hb-appendix-reference.xml" />
</chapter>
</part>
</book>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-06-07 18:06 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-07 18:05 [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened/selinux: hb-appendix-reference.xml hb-appendix-troubleshoot.xml hb-intro-concepts.xml hb-intro-enhancingsecurity.xml hb-intro-referencepolicy.xml hb-using-commands.xml hb-using-enforcing.xml hb-using-install.xml hb-using-permissive.xml hb-using-policymodules.xml selinux-handbook.xml JosA MarAa Alonso (nimiux)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox