* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened: hardenedfaq.xml selinux-faq.xml
@ 2011-10-28 18:25 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; only message in thread
From: JosA MarAa Alonso (nimiux) @ 2011-10-28 18:25 UTC (permalink / raw
To: gentoo-commits
nimiux 11/10/28 18:25:31
Modified: hardenedfaq.xml
Added: selinux-faq.xml
Log:
New spanish translation: selinux-faq.xml
Revision Changes Path
1.10 xml/htdocs/proj/es/hardened/hardenedfaq.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml?rev=1.10&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml?rev=1.10&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml?r1=1.9&r2=1.10
Index: hardenedfaq.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- hardenedfaq.xml 7 Jun 2011 19:11:44 -0000 1.9
+++ hardenedfaq.xml 28 Oct 2011 18:25:31 -0000 1.10
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml,v 1.9 2011/06/07 19:11:44 nimiux Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/hardenedfaq.xml,v 1.10 2011/10/28 18:25:31 nimiux Exp $ -->
<guide link="/proj/es/hardened/hardenedfaq.xml" lang="es">
<title>Preguntas de Uso Frecuente de Gentoo Hardened</title>
@@ -83,7 +83,7 @@
<p>
La respuesta a esta pregunta es muy subjetiva, y depende mucho de
-sus requisitos por lo que el proyecto Gentoo Hardened sólo persigue
+sus requisitos por lo que el proyecto Gentoo Hardened solo persigue
proporcionar las tecnologías y dejar la elección de cual usar al
usuario. Esta decisión requiere mucha investigación que esperamos
facilitar con esta documentación. Sin embargo, si tiene preguntas
@@ -101,8 +101,8 @@
<p>
Sí, es posible combinarlos ya que PaX y algunas características de
-Grsecurity funcionan con el RBAC de Grsecurity y SELinux. Sólo
-habría problemas si sólo puede usar un sistema de control de acceso
+Grsecurity funcionan con el RBAC de Grsecurity y SELinux. Solo
+habría problemas si solo puede usar un sistema de control de acceso
(sea RBAC o SELinux).
</p>
@@ -553,8 +553,8 @@
Para buscar en su sistema relocalizaciones de texto, puede usar el
programa <c>scanelf</c> de <c>app-misc/pax-utils</c>. Si quiere más
información sobre cómo usar el paquete <c>pax-utils</c> visite, por
-favor, la <uri link="/proj/en/hardened/pax-utils.xml">Guía de Gentoo
-de las utilidades PaX</uri> (en inglés).
+favor, la <uri link="/proj/es/hardened/pax-utils.xml">Guía de Gentoo
+de las utilidades PaX</uri>.
</p>
<note>
@@ -647,11 +647,11 @@
<p>
Pasar la opción <c>pax_softmode=1</c> en la línea de comandos del
núcleo activará el modo soft, el cual puede ser útil cuando arranquemos
-un sistema no preparado con un núcleo PaX kernel. En el modo soft
-PaX desactivará la mayor parte de las características por defecto
-a menos que se le indique lo contrario a través de las marcas. De forma
-similar, <c>pax_softmode=0</c> desactivará el modo soft que estaba
-activado en la configuración.
+un sistema no preparado con un núcleo PaX. En el modo soft PaX desactivará
+la mayor parte de las características por defecto a menos que se le
+indique lo contrario a través de las marcas. De forma similar,
+<c>pax_softmode=0</c> desactivará el modo soft que estaba activado en
+la configuración.
</p>
</body>
@@ -720,8 +720,8 @@
<body>
<p>
-Existe un <uri link="/proj/en/hardened/selinux-faq.xml">PUF específico de
-SELinux specific</uri> (en inglés).
+Existe una guía con <uri link="/proj/es/hardened/selinux-faq.xml">
+Preguntas frecuentes (FAQ) sobre SELinux</uri>.
</p>
</body>
1.1 xml/htdocs/proj/es/hardened/selinux-faq.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux-faq.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/hardened/selinux-faq.xml?rev=1.1&content-type=text/plain
Index: selinux-faq.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/hardened/selinux-faq.xml,v 1.1 2011/10/28 18:25:31 nimiux Exp $ -->
<guide lang="es">
<title>Preguntas frecuentes (FAQ) sobre SELinux en Gentoo Hardened</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="Traductor">
<mail link="nimiux"/>
</author>
<abstract>
Preguntas frecuentes (FAQ) sobre la integración de SELinux con Hardened.
Este documento con preguntas frecuentes es una colección de soluciones
que se han discutido en IRC, listas de correo, foros o en otros lugares.
</abstract>
<version>17</version>
<date>2011-10-25</date>
<faqindex>
<title>Preguntas</title>
<section>
<title>Introducción</title>
<body>
<p>
El uso de SELinux requiere que los administradores tengan un conocimiento
extenso de su sistema y una buena información de como se deben
comportar los procesos.. Aparte de nuestro <uri
link="/proj/es/hardened/selinux/selinux-handbook.xml">Manual de SELinux
para Gentoo Hardened</uri>, una serie de preguntas frecuentes nos
permite informar y ayudar a los usuarios en su experiencia diaria con
SELinux.
</p>
<p>
Estas preguntas es un resumen de las soluciones dadas en IRC, listas de
correo, foros o en otros lugares. Se centran en la integración de
SELinux integration en Gentoo Hardened, sin embargo, también surgen
preguntas generales sobre SELinux que se han ido incorporando igualmente.
</p>
</body>
</section>
</faqindex>
<chapter>
<title>Preguntas generales sobre soporte SELinux</title>
<section id="features">
<title>¿Fuerza SELinux los límites de los recursos?</title>
<body>
<p>
No, los límites de los recursos están fuera de la gestión de un sistema
de control de acceso. Si está buscando soporte en este tipo de
cuestiones, eche un vistazo a tecnologías como grsecurity, cgroups, pam
y otras del estilo.
</p>
</body>
</section>
<section id="grsecurity">
<title>¿Puede utilizar SELinux con grsecurity (y PaX)?</title>
<body>
<p>
Por supuesto, de hecho es lo que recomendamos. Si embargo, se recomienda
evitar el uso del soporte que tiene grsecurity para ACL ya que podría
ser redundante en el control de acceso de SELinux.
</p>
</body>
</section>
<section id="pie-ssp">
<title>¿Puedo utilizar SELinux con el compilador hardened (usando PIE-SSP)?</title>
<body>
<p>
Por supuesto, también recomendamos utilizar PaX para tener todas las
ventajas de las características PIE que ofrece el compilador.
</p>
</body>
</section>
<section id="rsbac">
<title>¿Puedo utilizar SELinux y RSBAC?</title>
<body>
<p>
Sí, SELinux y RSBAC se pueden utilizar conjuntamente, pero no lo
recomendamos. Ambos marcos de trabajo (RSBAC y la implementación de
SELinux encima del marco de trabajo de los módulos de seguridad de los
sistemas Linux) tienen un pequeño impacto en el rendimiento del sistema.
Si se habilitan ambos, se tendrá una penalización en el rendimiento,
obteniendo poc valor añadido ya que ambos ofrecen una funcionalidad
they both offer similar functionality.
</p>
<p>
En la mayoría de los casos, es más prudente utilizar RSBAC sin SELinux,
o SELinux sin RSBAC.
</p>
<!--
If users are unclear, mention that you can compile both in and then try to
only enable one (configuration wise), but that this has little benefit on
the performance (since the hooks are there, the checks that are made are just
a bit different but due to caching, the overhead of having it enabled versus
disabled is small anyhow).
-->
</body>
</section>
<section id="filesystem">
<title>¿Puede utilizar SELinux con cualquier sistema de ficheros?</title>
<body>
<p>
SELinux requiere acceso al contexto de seguridad de los ficheros para
funcionar correctamente. Para ello, SELinux utiliza los
<e>atributos extendidos de fichero</e> que deben por tanto ofrecer
los sistemas de ficheros con los que se opere. Si el sistema de
ficheros soporta los atributos extendidos de fichero y ha configurado
su núcleo para habilitar este soporte, entonces SELinux funcionará
en esos sistemas.
</p>
<p>
Los sistemas de ficheros generales, tales como: ext2, ext3, ext4, jfs,
xfs y btrfs ofrecen soporte para atributos extendidos (pero no
olvide habilitarlo en la configuración del núcleo), el sistema tmpfs
también ofrece este soporte (por ejemplo para que lo utilice udev). Si
su colección sistema de ficheros se limita a este conjunto, entonces
no debería tener problemas.
</p>
<p>
Se soportan también los sistemas de ficheros anticuados como vfat e
iso9660, pero con una importante limitación: todos los ficheros en cada
uno de los sistemas de ficheros tendrán la misma información de contexto
de seguridad ya que estos sistemas no ofrecen soporte para atributos
extendidos de ficheros.
</p>
<p>
Se puede dar soporte a Los sistemas de ficheros en red de la misma forma
que a los sistemas de ficheros anticuados (todos los ficheros comparten
el mismo contexto de seguridad). Sin embargo, se ha realizado algún
esfuerzo de desarrollo para ofrecer atributos extendidos en sistemas
populares como NFS. Aunque todavía estamos lejos de que esto se pueda
utilizar en un sistema de producción, parece que algún día también se
ofrecerá soporte completo para estos sistemas en SELinux.
</p>
</body>
</section>
<section id="nomultilib">
<title>¿Puedo utilizar SELinux con AMD64 no-multilib?</title>
<body>
<!-- FAQ might be removed in the future since it is now obvious -->
<p>
Sí, simplemente utilice el perfil
<path>hardened/linux/amd64/no-multilib/selinux</path> y ya estará
preparado.
</p>
</body>
</section>
<section id="ubac">
<title>¿Qué es exactamente UBAC?</title>
<body>
<p>
UBAC (<e>User Based Access Control</e>) o Control de Acceso Basado en
Usuario, introduce límites adicionales cuando se usa la directriz de
SELinux. Los dominios o tipos que participan y que han sido
<e>ambos</e> marcados como <c>ubac_constrained_type</c> (que es un
atributo) tendrán los privilegios permitidos en efecto únicamente si
ambos están corriendo con el mismo contexto de usuario SELinux.
</p>
<pre caption="Dominios y sus contextos de usuario SELinux">
<comment># La regla permisiva de SELinux</comment>
allow foo_t bar_t:file { read };
<comment># Esto funcionará:</comment>
staff_u:staff_r:foo_t reads file with type staff_u:object_r:bar_t
<comment># Esto no será permitido:</comment>
user_u:user_r:foo_t reads file with type staff_u:object_r:bar_t
</pre>
<p>
Desde luego, este no es siempre el caso. Aparte del requerimiento
mencionado anteriormente de que ambos tipos sean
<c>ubac_constrained_type</c>, si el dominio origen es <c>sysadm_t</c>,
entonces la limitación no tendrá efecto (el dominio <c>sysadm_t</c>
está exento de las limitaciones UBAC). También, si el usuario
SELinux origen o destino es <c>system_u</c> entonces la limitación
tampoco tendrá efecto.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Utilizar SELinux</title>
<section id="enable_selinux">
<title>¿>Cómo habilito SELinux?</title>
<body>
<p>
Esto se explica en el <uri
link="/proj/es/hardened/selinux/selinux-handbook.xml">Manual de SELinux
para Gentoo</uri> en el capítulo <e>Usar SELinux en Gentoo Hardened</e>.
</p>
</body>
</section>
<section id="switch_status">
<title>¿Como cambio entre los modos permissive y enforcing (permisivo y forzado)?</title>
<body>
<p>
La forma más fácil es utilizar la orden <c>setenforce</c>. Con
<c>setenforce 0</c> le indica a SELinux que quiere trabajar en modo
permisivo. De igual modo, con <c>setenforce 1</c> le indica a SELinux
para que trabaje en modo forzado.
</p>
<p>
Puede también añadir una opción a l núcleo <c>enforcing=0</c> o
<c>enforcing=1</c> en la configuración del gestor de arranque (o durante
la rutina de inicio del sistema). Esto le permite correr SELinux en modo
permisivo o forzado desde que el sistema se inicia.
</p>
<p>
El estado por defecto del sistema se guarda en
<path>/etc/selinux/config</path>.
</p>
</body>
</section>
<section id="disable_selinux">
<title>¿Cómo deshabilito SELinux completamente?</title>
<body>
<p>
Puede ocurrir que, ejecutar SELinux en modo permisivo no sea suficiente
para corregir apropiadamente los problemas que vayan surgiendo. Para
deshabilitar SELinux completely, necesitará editar
<path>/etc/selinux/config</path> y ajustar <c>SELINUX=disabled</c>.
A continuación, deberá reiniciar su sistema.
</p>
<impo>
Cuando esté corriendo su sistema con SELinux deshabilitado, deberá iniciar
en modo permisivo y etiquetar de nuevo todo el sistema de ficheros. Las
actividades que se realizaron mientras SELinux estaba deshabilitado
podrían haber creado nuevos ficheros y haber eliminado las etiquetas
de algunos ficheros ya existentes, causando que estos ficheros no
dispongan de contexto de seguridad.
</impo>
</body>
</section>
<section id="matchcontext">
<title>¿Cómo averiguo qué regla de contexto de fichero se está utilizando para un fichero en particular?</title>
<body>
<p>
Si utiliza la orden <c>matchpathcon</c>, obtendrá el contexto de seguridad
que se debería estar utilizando para una determinada ruta (sea fichero o
directorio), sin embargo, esto no le muestra que regla se utiliza para
deducirlo. Para ello, puede utilizar <c>findcon</c>:
</p>
<pre caption="Usar findcon">
~# <i>findcon /etc/selinux/strict/contexts/files/file_contexts -p /lib64/rc/init.d</i>
/.* system_u:object_r:default_t
/lib64/rc/init\.d(/.*)? system_u:object_r:initrc_state_t
/lib64/.* system_u:object_r:lib_t
</pre>
<p>
Cuando las utilidades de SELinux están tratando de aplicar un contexto,
intentarán que concuerde la regla más específica, por lo que, en el caso
de arriba es la que nos lleva al contexto initrc_state_t.
</p>
<p>
La más específica significa, en el orden de pruebas:
</p>
<ol>
<li>
Si la línea A contiene una expresión regular y la línea B no la tiene,
entonces la línea B es más específica.
</li>
<li>
Si el número de caracteres antes de la primera expresión regular en la
línea A es menor que el número de caracteres antes de la primera
expresión regular en la línea B, entonces la línea B es más específica.
</li>
<li>
Si el número de caracteres en la línea A es menor que en la línea B,
entonces la línea B es más específica.
</li>
<li>
Si la línea A no mapea a un tipo específico de SELinux type y la línea
B sí lo hace, entonces la línea B es más específica.
</li>
</ol>
<p>
Sin embargo, cuando añada sus propios contextos de fichero (utilizando
<c>semanage</c>), estas condiciones no se aplican. En lugar de esto,
las herramientas como <c>restorecon</c> ¡tomarán la <e>última</e>
coincidencia dentro de los contextos de fichero localmente añadidos!
Puede comprobar el contenido de las reglas añadidas localmente en
<path>/etc/selinux/strict/contexts/files/file_contexts.local</path>
(sustituya <path>strict</path> con su tipo SELinux).
</p>
</body>
</section>
<section id="localpolicy">
<title>¿Cómo realizo pequeños cambios (adiciones) a la directriz?</title>
<body>
<p>
Si está interesado en el desarrollo de SELinux en Gentoo Hardened,
por favor, eche un vistazo a la
<uri link="/proj/en/hardened/selinux-development.xml">Guía de
desarrollo de SELinux</uri> y otra documentación mostrada en la
<uri link="/proj/en/hardened/selinux/index.xml">página de proyecto de
SELinux</uri> (en inglés).
</p>
<p>
Sin embargo, en alguna ocasión, necesitará conservar algunos cambios
en su directriz debido a cómo ha configurado su sistema o cuando
necesite permitir alguna acción que no vaya a ser aceptada como un
cambio en la directriz que afecta a toda la distribución. En ese
caso, continúe leyendo.
</p>
<p>
Las actualizaciones de la directriz son posibles únicamente cuando
necesite <e>permitir</e> privilegios adicionales. No es posible
eliminar reglas de la directriz, solo mejorarlas. Para mantener
su propio conjunto de reglas adicionales, cree un fichero en el
que conserve sus cambios. En el siguiente ejemplo, usaré el
término <path>fixlocal</path>, sustitúyalo por el nombre que
desee, pero mantenga ese nombre consistente. En el fichero
(<path>fixlocal.te</path>) escriba el siguiente texto
(de nuevo, sustituya <path>fixlocal</path> por el nombre que
haya elegido):
</p>
<pre caption="Contenido de fixlocal.te">
policy_module(fixlocal, 1.0)
require {
<comment># Declaraciones de tipos, clases y permisos usados</comment>
}
<comment># Declaraciones de reglas de directriz</comment>
</pre>
<p>
En este fichero puede añadir las reglas que desee. En el siguiente
ejemplo, añadiremos tres reglas:
</p>
<ol>
<li>
Conceder a <c>mozilla_t</c> el privilegio <c>execmem</c> (basado
en una denegación que se aplica cuando mozilla no se puede
iniciar).
</li>
<li>
Permitir a <c>ssh_t</c> conectar con cualquier puerto aparte del
puerto SSH.
</li>
<li>
Permitir al dominio <c>user_t</c> enviar mensajes directamente al
registrador del sistema.
</li>
</ol>
<pre caption="Contenido de fixlocal.te">
policy_module(fixlocal, 1.0)
require {
type mozilla_t;
type ssh_t;
type user_t;
class process { execmem };
}
<comment># Conceder a mozilla el privilegio execmem</comment>
allow mozilla_t self:process { execmem };
<comment># Permitir al cliente SSH conectar a cualquier puerto (tal y como indica el usuario
# a través de la orden # "ssh -p <númerodepuerto> ...")</comment>
corenet_tcp_connect_all_ports(ssh_t)
<comment># Permitir al dominio user_t enviar mensajes al registrador del sistema</comment>
logging_send_syslog_msg(user_t)
</pre>
<p>
Si necesita ofrecer sentencias de permisión (como la descrita arriba
para el dominio <c>mozilla_t</c>), asegúrese de que el tipo
(<c>mozilla_t</c>), clase (<c>process</c>) y privilegio (<c>execmem</c>)
se mencionan en el párrafo <c>require { ... }</c>.
</p>
<p>
Cuanto utilice nombres de interfaz, asegúrese de que los tipos
(<c>ssh_t</c> y <c>user_t</c>) se mencionan en el párrafo
<c>require { ... }</c>.
</p>
<p>
Para encontrar el nombre adecuado de la interfaz (como
la <c>corenet_tcp_connect_all_ports</c> de arriba), puede, bien, echar
un vistazo en línea a la <uri
link="http://oss.tresys.com/docs/refpolicy/api/">API de la Directriz
de Referencia de SELinux</uri> o, si se ha construido
<c>sec-policy/selinux-base-policy</c> con el ajuste USE <e>doc</e>,
en los ficheros
<path>/usr/share/doc/selinux-base-policy-.*/html</path>. Desde luego,
también puede pedir ayuda en el canal <c>#gentoo-hardened</c> de
irc.freenode.net, la lista de correo, los foros, etc. para encontrar
las reglas y sentencias adecuadas para su caso.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Mensajes de error del núcleo SELinux</title>
<section id="register_security">
<title>Obtengo un error register_security cuando arranca el sistema</title>
<body>
<p>
Durante el arranque del sistema, se muestra el siguiente mensaje:
</p>
<pre caption="Mensaje del núcleo sobre register_security">
There is already a security framework initialized, register_security failed.
Failure registering capabilities with the kernel
selinux_register_security: Registering secondary module capability
Capability LSM initialized
</pre>
<p>
No hay nada de lo que preocuparse (es perfectamente normal).
</p>
<p>
Esto significa que el módulo de capacidad LSM no se pudo registrar como
módulo principal ya que SELinux es el módulo principal. El tercer mensaje
indica que ha registrado SELinux como módulo secundario.
</p>
</body>
</section>
<section id="permission_not_defined">
<title>Obtengo un mensaje 'Permission ... in class ... not defined' durante el arranque</title>
<body>
<p>
Durante el arranque del sistema, se muestra el siguiente mensaje:
</p>
<pre caption="Mensaje del núcleo sobre permiso(s) no definido(s)">
SELinux: 2048 avtab hash slots, 16926 rules.
SELinux: 2048 avtab hash slots, 16926 rules.
SELinux: 6 users, 6 roles, 1083 types, 34 bools
SELinux: 77 classes, 16926 rules
SELinux: Permission read_policy in class security not defined in policy.
SELinux: Permission audit_access in class file not defined in policy.
SELinux: Permission audit_access in class dir not defined in policy.
SELinux: Permission execmod in class dir not defined in policy.
...
SELinux: the above unknown classes and permissions will be denied
SELinux: Completing initialization.
</pre>
<p>
Esto significa que el núcleo Linux que está arrancado ofrece soporte
para permisos que no están definidos en la directriz (que a su vez
son ofertados a través del paquete
<c>sec-policy/selinux-base-policy</c>). Si no aparecen más errores
durante las operaciones normales, entonces puede ignorarlo (los
permisos formarán parte de las definiciones de directriz que se
realicen en adelante).
</p>
</body>
</section>
</chapter>
<chapter>
<title>SELinux y Gentoo</title>
<section id="no_module">
<title>Obtengo un error de que un módulo de SELinux no está presente cuando utilizo emerge</title>
<body>
<p>
Cuando se intenta utilizar <c>emerge</c>, aparece el siguiente error:
</p>
<pre caption="Mensaje de error de emerge acerca del módulo SELinux">
!!! SELinux module not found. Please verify that it was installed.
</pre>
<p>
Esto indica que el módulo SELinux para portage no se encuentra o está
dañado. Las versiones recientes de Portage ofrecen este módulo
directamente, pero los contextos de seguridad de los ficheros
necesarios pueden ser erróneos para su sistema. Intente etiquetar
de nuevo los ficheros de paquete portage:
</p>
<pre caption="Etiquetar de nuevo todos los ficheros de portage">
~# <i>rlpkg portage</i>
</pre>
</body>
</section>
<section id="loadpolicy">
<title>Aparece el mensaje 'FEATURES variable contains unknown value(s): loadpolicy'</title>
<body>
<p>
Cuando se ejecuta emerge, aparece el siguiente error:
</p>
<pre caption="Error de emerge acerca de loadpolicy">
FEATURES variable contains unknown value(s): loadpolicy
</pre>
<p>
Esto es un remanente del conjunto de módulos de directriz SELinux
antiguos en los que se necesitaba que esta CARACTERISTICA (FEATURE)
estuviera disponible. Aunque los paquetes más recientes ya no ofrecen
soporte para esta CARACTERISTICA, éstos están todavía en la fase de
pruebas (~arch) por lo que el perfil actual de SELinux todavía ofrece
este valor. Portage, sin embargo, ya tiene en cuenta que esta
CARACTERISTICA ya no es soportada y por ello protesta.
</p>
<p>
Le recomendamos que utilice versiones en prueba (~arch) para todos
los paquetes de la categoría sec-policy, y defina
<c>FEATURES="-loadpolicy"</c> para deshabilitar este error
(que es meramente cosmético).
</p>
<p>
Una vez que los módulos de directriz hayan pasado a la fase estable,
el perfil de SELinux se actualizará para eliminar este ajuste.
</p>
</body>
</section>
<section id="conflicting_types">
<title>Mientras utilizo rlpkg, obtengo: 'conflicting specifications for ... and ..., using ...'</title>
<body>
<p>
Cuando se trata de etiquetar de nuevo un paquete
(<c>rlpkg nombredepaquete</c>) o el propio sistema (<c>rlpkg -a -r</c>)
se obtiene un error similar al siguiente:
</p>
<pre caption="La orden rlpkg protesta sobre especificaciones en conflicto">
filespec_add: conflicting specifications for /usr/bin/getconf and
/usr/lib64/misc/glibc/getconf/XBS5_LP64_OFF64, using
system_u:object_r:lib_t
</pre>
<p>
En la mayoría de las ocasiones esto se debe a ficheros con enlaces
duros (hard links). Recuerde, SELinux utiliza los atributos extendidos
del sistema de ficheros para almacenar el contexto de seguridad de los
ficheros. Si dos rutas distintas apuntan al mismo fichero mediante
el uso de enlaces duros (esto es, los ficheros comparten el mismo
inodo), entonces ambos ficheros tendrán el mismo contexto de seguridad.
</p>
<p>
La solución depende de cada caso en particular. Se muestran a continuación
varias formas de solucionar esto en el orden en el que más probable se
obtenga un remedio:
</p>
<ol>
<li>
Aunque ambos ficheros son el mismo, no se utilizan en el mismo
contexto. En estos casos, se recomienda eliminar uno de los
ficheros y copiar el otro fichero al primero (<c>rm B; cp A B</c>).
De esta forma, ambos ficheros tienen inodos diferentes y se
pueden etiquetar de forma correcta.
</li>
<li>
Ambos ficheros se utilizan para el mismo propósito. En este caso,
sería mejor etiquetar el fichero que no ha sido etiquetado de
forma correcta (digamos, un binario en algún lugar de la ubicación
<path>/usr/lib64</path>) utilizando <c>semanage</c>
(<c>semanage fcontext -a -t dominio_correcto
/usr/lib64/camino/al/fichero</c>)
</li>
</ol>
<p>
No es mala idea informar (después de comprobar que nadie lo ha hecho ya)
de esto en el <uri link="https://bugs.gentoo.org">bugzilla de
Gentoo</uri> para que se actualicen las directrices correctamente.
</p>
</body>
</section>
<section id="portage_libsandbox">
<title>Cuando se instala un paquete, ld.so protesta: 'object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored'</title>
<body>
<p>
Mientras se instala un paquete, puede aparecer el siguiente mensaje
de error:
</p>
<pre caption="Mensaje de error cuando se está instalando un paquete">
>> Installing (1 of 1) net-dns/host-991529
>>> Setting SELinux security labels
ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
</pre>
<p>
Este mensaje debería ocurrir <e>únicamente</e> después de que
aparezca el mensaje <e>Setting SELinux security labels</e>. Ocurre
porque SELinux le indica a glibc que deshabilite <c>LD_PRELOAD</c>
(y otras variables de entorno que se consideran dañinas) durante
los cambios entre dominios. Aquí, portage invoca la orden
<c>setfiles</c> (parte de la instalación de SELinux) cuando
cambia desde portage_t a setfiles_t, lo cual limpia la variable de
entorno.
</p>
<p>
Creemos que en esta ocasión es más seguro confiar en la directriz
de SELinux (ya que setfiles ejecuta de todas formas su propio
dominio confinado) en lugar de actualizar la directriz para
permitir el cambio desde portage_t a setfiles_t sin limpiar
estas variables de entorno. Observe que <e>libsandbox.so no se
deshabilita durante las construcciones e instalaciones de
paquetes</e>, únicamente durante la actividad en la que Portage
etiqueta los ficheros recién instalados.
</p>
<p>
Por lo tanto, este error es cosmético, desde nuestro punto de vista,
y se puede ignorar (desafortunadamente no se puede ocultar).
</p>
</body>
</section>
<section id="emergefails">
<title>Emerge no funciona, muestra el mensaje: 'Permission denied: /etc/make.conf'</title>
<body>
<p>
Esto es de esperar si no está utilizando el rol <c>sysadm_r</c>.
Cualquier actividad relacionada con Portage requiere que esté en
el rol <c>sysadm_r</c>. Para cambiar a ese rol, en primer lugar
valide si actualmente está en <c>staff_u</c> (o, si añadió sus
propias identidades SELinux, un usuario que tenga permiso para
cambiar al rol <c>sysadm_r</c>). A continuación ejecute
<c>newrole -r sysadm_r</c> para hacer el cambio.
</p>
<pre caption="Cambiar a sysadm_r">
~$ <i>emerge --info</i>
Permission denied: '/etc/make.conf'
~$ <i>id -Z</i>
staff_u:staff_r:staff_t
~$ <i>newrole -r sysadm_r</i>
Password: <comment># Introduzca su clave de usuario</comment>
</pre>
<p>
Esto es también necesario si ha entrado en el sistema como root
pero a través de SSH. El comportamiento por defecto es que SSH
define el rol más bajo para un usuario en particular cuando éste
se conecta. No debería permitir entrar como root desde un equipo
remoto bajo ningún concepto.
</p>
</body>
</section>
<section id="cronfails">
<title>Cron no puede cargar el crontab de root: '(root) ENTRYPOINT FAILED (crontabs/root)'
</title>
<body>
<p>
Cuando obtenga el error mencionado con una crontab de root o una crontab
de un usuario administrativo, pero no con una crontab de un usuario normal,
entonces deberá comprobar el contexto del fichero crontab:
</p>
<pre caption="Comprobar el contexto del fichero crontab">
~# <i>ls -Z /var/spool/cron/crontabs/root</i>
staff_u:object_r:user_cron_spool_t /var/spool/cron/crontabs/root
</pre>
<p>
A continuación, comprueba que el contexto por defecto es para el
usuario correcto (en este caso, root) cuando se origina desde
el dominio <c>crond_t</c>:
</p>
<pre caption="Comprobar el contexto por defecto del usuario root">
~# <i>getseuser root system_u:system_r:crond_t</i>
seuser: root, level (null)
Context 0 root:sysadm_r:cronjob_t
Context 1 root:staff_r:cronjob_t
</pre>
<p>
Como puede ver, el contexto por defecto es siempre para el usuario de
SELinux <c>root</c>. Sin embargo, el contexto del fichero
<path>/var/spool/cron/crontabs/root</path> en el ejemplo de arriba
es para el usuario SELinux staff_u. Por lo tanto, cron no podrá leer
este fichero (el tipo <c>user_cron_spool_t</c> es un tipo UBAC con
limitación).
</p>
<p>
Para corregir esto, cambie el usuario del fichero a root:
</p>
<pre caption="Cambiar el usuario SELinux del fichero crontab de root">
~# <i>chcon -u root /var/spool/cron/crontabs/root</i>
</pre>
<p>
Otra forma de corregirlo sería deshabilitar UBAC completamente. Esto
se puede hacer con <c>USE="-ubac"</c>.
</p>
</body>
</section>
<section id="missingdatum">
<title>Cuando consulto la directriz, obtengo: 'ERROR: could not find datum for type ...'</title>
<body>
<p>
Cuando se utiliza <c>seinfo</c> o <c>sesearch</c> para consultar la
directriz en el sistema, se obtienen errores similares a:
</p>
<pre caption="Forzando el error 'could not find datum'">
~# <i>seinfo -tasterisk_t</i>
ERROR: could not find datum for type asterisk_t
</pre>
<p>
Esto, en la mayoría de las ocasiones, sucede porque sus herramientas
están utilizando una directriz de un nuevo binario para forzar la
directriz, sin embargo, otro binario para realizar la consulta.
Puede verificar si este es el caso, listando la última fecha de
modificación de los ficheros:
</p>
<pre caption="Comprobar la última fecha de modificación de los ficheros de directriz">
~# <i>ls -ltr /etc/selinux/strict/policy/policy.*</i>
</pre>
<p>
El último fichero modificado debería ser el mismo que el devuelto
por <path>/selinux/policyvers</path>:
</p>
<pre caption="Comprobar la versión de directriz en tiempo de ejecución">
~# <i>cat /selinux/policyvers; echo</i>
24
</pre>
<p>
Si éste no es el caso (que seguramente es la razón principal por la
que está leyendo estas preguntas frecuentes) entonces intente
forzar la versión de la directriz de utilidades a la versión
correcta:
</p>
<pre caption="Editar semanage.conf">
~# <i>vim /etc/selinux/semanage.conf</i>
<comment># Busque la línea policy-version y elimine el comentario para definirlo a la versión correcta</comment>
policy-version = <i>24</i>
</pre>
<impo>
Si está actualizando el núcleo de su sistema, se puede dar soporte
a versiones más altas. En este caso, bien, deje la varible de nuevo
sin definir para "saltar" de forma automática a una versión más alta
of fuércela a la versión más alta.
</impo>
</body>
</section>
<section id="recoverportage">
<title>Portage no puede etiquetar los ficheros porque "setfiles" ha dejado de funcionar</title>
<body>
<p>
Portage utiliza la orden <c>setfiles</c> para definir la etiquetas de los
ficheros que instala. Sin embargo, esta orden es un ejecutable enlazado
dinámicamente, por lo que cualquier actualización, depende de la librerías
enlazadas (<path>libselinux.so</path>, <path>libsepol.so</path>,
<path>libaudit.so</path> y por supuesto <path>libc.so</path>), las
cuales podrían causar que la aplicación fallara. La solución estándar de
Gentoo (<c>revdep-rebuild</c>) no funcionará ya que la herramienta
intentará reconstruir policycoreutils, que no podrá instalarse porque
Portage no puede definir las etiquetas de los ficheros.
</p>
<p>
La solución es reconstruir policycoreutils deshabilitando el soporte
selinux de Portage y etiquetar manualmente los ficheros instalados
usando <c>chcon</c>, basado en los datos que ofrece
<c>matchpathcon</c>.
</p>
<pre caption="Recuperarse de fallos de instalación de Portage">
# <i>FEATURES="-selinux" emerge --oneshot policycoreutils</i>
# <i>for FILE in $(qlist policycoreutils); do \
CONTEXT=$(matchpathcon -n ${FILE}); chcon ${CONTEXT} ${FILE}; done</i>
</pre>
<p>
Ahora, Portage funcionará correctamente, etiquetando los ficheros
de la forma correcta.
</p>
</body>
</section>
<section id="nosuid">
<title>Las aplicaciones no cambian en una partición montada con nosuid</title>
<body>
<p>
Si tiene sistemas de ficheros montados con la opción <c>nosuid</c>, entonces
las aplicaciones iniciadas desde estos sistemas de ficheros no cambiarán
al dominio apropiado. Esto se ha hecho de forma intencionada.
</p>
<p>
Por tanto, un binario <c>passwd</c>, aunque esté etiquetado de forma
correcta con <e>passwd_exec_t</e>, no cambiará al dominio <e>passwd_t</e>
si ese binario está almacenado en un sistema de ficheros montado con
<c>nosuid</c>.
</p>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2011-10-28 18:25 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-28 18:25 [gentoo-commits] gentoo commit in xml/htdocs/proj/es/hardened: hardenedfaq.xml selinux-faq.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