44 seguridad y se linux

731
Seguridad y SELinux
44.1. Mecanismos de Control de Acceso (ACMs)
Esta sección proporciona una introducción básica a los Mecanismos de Control de Acceso (ACMs).
Los ACMs proporcionan un medio para los administradores de sistemas para controlar que usuarios
y que porcesos pueden acceder a diferentes archivos, disositivos, interfaces, etc, en un sistemade
computador. Es una de las consideraciones principales al asegurar un sistema de computadores o
una red de cualquier tamaño.
44.1.1. Control de Acceso Discrecional (DAC)
Control de Acceso Discrecional (DAC) edfine los controles de acceso básicos en un sistema de
archivos. Este es el típico control de acceso que proporcionan los permisos de archivos, etc. Tal
acceso se encentra generalmente a la discreción del dueño del objeto (archivo, directorio, dispositivo,
etc).
DAC provides a means of restricting access to objects based on the identity of the users or groups
(subjects) that try to access those objects. Depending on a subject's access permissions, they may
also be able to pass permissions to other subjects.
44.1.2. Control de Acceso Mandatorio (MAC)
El Control de Acceso Mandatorio (MAC) es un mecanismo de seguridad que restringe el nivel de
control que los usuarios (sujetos) tienen sobre otros objetos que crean. DE manera opuesta que
en una implementación DAC, en donde los usuarios tienen control total sobre sus propios archivos,
directorios, etc, MAC añade etiquetas adicionales o categorías a todos los objetos del sistemade
archivos. Los usuarios y los procesos tienen que tener el acceso apropiado a estas categorias antes
de que puedan interactuar con estos objetos.
In Red Hat Enterprise Linux, MAC is enforced by SELinux. For more information, refer to
Sección 44.2, “Introducción a SELinux”.
44.1.3. Control de Acceso basado en Roles (RBAC)
El Control de Acceso basado en Roles (RBAC) es un método alternativo de controlar el acceso de
los usuarios a objetos del sistema de archivos. En vez de que los permisos de usuario controlen
el acceso, el administrador del sistema establece Roles basados en requeriemeintos funcionales
empresariales o un criterio similar. Estos Roles tienen diferentes tipos y distintos niveles de acceso a
objetos.
In contrast to DAC or MAC systems, where users have access to objects based on their own and the
object's permissions, users in an RBAC system must be members of the appropriate group, or Role,
before they can interact with files, directories, devices, etc.
Desde un punto de vista administrativo, esto hace mucho más fácil controlar quienes tienen acceso a
varias partes del sistema de archivos con tan sólo controlar sus mermbresías a grupos.

732
Archivos relacionados con SELinux
44.1.4. Seguridad Multi-Nivel (MLS)
Multi-Level Security (MLS) is a specific Mandatory Access Control (MAC) security scheme. Under this
scheme, processes are called Subjects. Files, sockets and other passive operating system entities are
called Objects. For more information, refer to Sección 44.6, “Seguridad Multi-Nivel (MLS)”.
44.2. Introducción a SELinux
Security-Enhanced Linux (SELinux) es una arquitectura de seguridad integrada en el kernel 2.6.x
utilizando los Módulos de seguridad de Linux (LSM). Es un proyecto de la agencia de seguridad de los
Estados Unidos (NSA) y la comunidad SELinux. La integración de SELinux en Red Hat Enterprise
Linux fue un esfuerzo conjunto entre NSA y Red Hat.
44.2.1. Sinopsis de SELinux
SELinux provides a flexible Mandatory Access Control (MAC) system built into the Linux kernel. Under
standard Linux Discretionary Access Control (DAC), an application or process running as a user (UID
or SUID) has the user's permissions to objects such as files, sockets, and other processes. Running a
MAC kernel protects the system from malicious or flawed applications that can damage or destroy the
system.
SELinux define los derechos de acceso y transmisión de cada usuario, aplicación, proceso y archivo
en el sistema. SELinux gobierna luego la interacción de estas entidades mediante el uso de políticas
de seguridad que especifican qué tan estricto debe ser una instalación de Red Hat Enterprise Linux.
Diariamente, los usuarios del sistema no son concientes de la presencia de SELinux. Sólo los
administradores de sistemas necesitan considerar qué tan estricta debe ser la política implementada
en los entornos de los servidores. Las políticas pueden ser tan estrictas o indulgentes como sea
necesario. Las políticas son bastante detalladas, lo cual proporciona un control detallado y completo
del kernel de SELinux sobre el sistema entero.
El proceso de toma de decisiones de SELinux
When a subject, (for example, an application), attempts to access an object (for example, a file), the
policy enforcement server in the kernel checks an access vector cache (AVC), where subject and
object permissions are cached. If a decision cannot be made based on data in the AVC, the request
continues to the security server, which looks up the security context of the application and the file in a
matrix. Permission is then granted or denied, with an avc: denied message detailed in /var/log/
messages if permission is denied. The security context of subjects and objects is applied from the
installed policy, which also provides the information to populate the security server's matrix.
Consulte el siguiente diagrama:

733
Figura 44.1. Proceso de decisión de SELinux
Modos de ope ración de SELinux
En vez de ejecutarse en el modo obediente, SELinux puede ejecutarse en el modo permisivo, en
donde el AVC es revisado y las negaciones son registradas sin que SELinux aplique la política. Esta
propiedad es útil durante el periodo de soluciones de errores y para desarrollar o mejorar políticas de
SELinux.
For more information about how SELinux works, refer to Sección 44.2.3, “Recursos adicionales”.
44.2.2. Archivos relacionados con SELinux
Las siguientes secciones describen los archivos de configuración de SELinux y los sistemas de
archivos relacionados.
44.2.2.1. El seudo sistema de archivos de SELinux
El seudo sistema de archivos /selinux/ contiene comandos que son utilizados por el subsistema
del kernel. Esta clase de sistema de archivos es similar al seudo sistema de archivos /proc/.
Ni los administradores ni los usuarios necesitan normalmente manipular este componente.
El siguiente ejemplo muestra contenidos de ejemplo del directorio /selinux/:
-rw-rw-rw- 1 root root 0 Sep 22 13:14 access
dr-xr-xr-x 1 root root 0 Sep 22 13:14 booleans
--w------- 1 root root 0 Sep 22 13:14 commit_pending_bools
-rw-rw-rw- 1 root root 0 Sep 22 13:14 c onte xt
-rw-rw-rw- 1 root root 0 Sep 22 13:14 create
--w------- 1 root root 0 Sep 22 13:14 disa ble
-rw-r--r-- 1 root root 0 Sep 22 13:14 e nforce
-rw------- 1 root root 0 Sep 22 13:14 loa d
-r--r--r-- 1 root root 0 Sep 22 13:14 mls

734
-r--r--r-- 1 root root 0 Sep 22 13:14 polic yvers
-rw-rw-rw- 1 root root 0 Sep 22 13:14 relabel
-rw-rw-rw- 1 root root 0 Sep 22 13:14 user
Por ejemplo, al ejecutar el comando cat en el archivo enforce revela 1 para el modo obediente o 0
para el modo permisivo.
44.2.2.2. Archivos de configuración de SELinux
Las siguientes secciones describen los archivos de políticas y configuración de SELinux y los
sistemas de archivos relacionados ubicados en el directorio /etc/.
44.2.2.2.1. El archivo de configuración /etc/sysconfig/selinux
There are two ways to configure SELinux under Red Hat Enterprise Linux: using the SELinux
Administration Tool (system-config-selinux), or manually editing the configuration file (/etc/
sysconfig/selinux).
El archivo /etc/sysconfig/selinux es el archivo de configuración principal para activar o
desactivar SELinux. También permite establecer la política a cumplir y la forma en que ésta debe ser
seguida.
Nota
El archivo /etc/sysconfig/selinux es un enlace simbólico al archivo de
configuración /etc/selinux/config.
A continuación se muestran los grupos de opciones disponibles para la configuración:
• SELINUX=enforcing|permissive|disabled — Define el estado principal de SELinux en un
sistema.
• enforcing (obediente) — La política de seguridad de SELinux entra en vigor.
• permissive (permisiva) — El sistema SELinux crea advertencias pero no aplica la política.
Esta opción es útil durante la depuración y solución de errores. En el modo permisivo, muchas
más negaciones son registradas ya que los sujetos pueden continuar con las acciones que
de otra forma serían negadas en el modo obediente. Por ejemplo, al explorar el árbol de un
directorio en modo permisivo crearía mensajes avc: deniedpor cada nivel del directorio que
sea leído. En modo obediente, SELinux detendría la exploración inicial evitando así la ocurrencia
de más mensajes de negación.
• disabled (deshabilitado) — SELinux es completamente desactivado. Los enlaces de SELinux
son desprendidos del kernel y se borra el registro del seudo sistema de archivos.

735
Tip
Las acciones que son ejecutadas mientras SELinux está desactivado pueden
resultar en la perdida de los contextos de seguridad correctos del sistema de
archivos. En otras palabras, la pérdida de los contextos de seguridad definidos
por la política. La manera más adecuada de recuperar los contextos es creando
el archivo ./autorelabel y reiniciando la máquina. Esto hace que la etiquetas
sean creadas durante las primeras etapas del proceso de arranque, antes
de que cualquier servicio este siendo ejecutado en el sistema. Al usar este
procedimiento se asegura que ningún proceso cree accidentalmente archivos
con un contexto erróneo o sean iniciados en un contexto erróneo.
Es posible utilizar el comando fixfiles relabel antes de activar SELinux
para etiquetar el sistema de archivos. Este método no es recomendado porque
es posible que algunos procesos permanezcan en ejecución dentro del contexto
erróneo después de que el comando ha etiquetado el sistema de archivos. Estos
procesos podrían crean archivos que también estarían en un contexto erróneo.
Nota
Espacios en blanco adicionales al final de las líneas de configuración o como
líneas extras al final del archivo pueden causar comportamientos inesperados. Por
seguridad, remueva los espacios en blanco que no sean necesarios.
• SELINUXTYPE=targeted|strict — Especifica la política que debe ser aplicada por SELinux.
• targeted — Sólo se protegen los demonios de red objetivos.
Importante
Los siguientes demonios están protegidos en la política de objetivos
predeterminada: dhcpd, httpd (apache.te), named, nscd, ntpd,
portmap, snmpd, squid y syslogd. El resto del sistemase ejecuta en el
dominio unconfined_t. Este dominio le permite a los sujetos y objetos con este
contexto de seguridad operar utilizando la seguridad estándar de Linux.
Los archivos de políticas para esos demonios están en /etc/selinux/
targeted/src/policy/domain/program. Estos archivos están sujetos a
cambios en las nuevas versiones de Red Hat Enterprise Linux.
Policy enforcement for these daemons can be turned on or off, using Boolean values controlled
by the SELinux Administration Tool (system-config-selinux).
Setting a Boolean value for a targeted daemon to 1 disables SELinux protection for the daemon.
For example, you can set dhcpd_disable_trans to 1 to prevent init, which executes apps
labeled dhcpd_exec_t, from transitioning to the dhcpd_t domain.
Utilice el comando getsebool -a para listar todos los valores booleanos de SELinux. El
siguiente es un ejemplo de uso del comando setsebool para establecer un booleano de

736
SELinux. La opción -P hace que el cambio sea permanente. Si esta opción no se especifica, el
valor booleano regresará a 1 durante el inicio del sistema.
setsebool -P dhcpd_disa ble _trans=0
• strict — Protección completa de SELinux para todos los demonios. Los contextos de
seguridad para todos los sujetos y objetos son definidos. Cada acción es procesada por el
servidor de ejecución de políticas.
• SETLOCALDEFS=0|1 — Controls how local definitions (users and booleans) are set. Set
this value to 1 to have these definitions controlled by load_policy from files in /etc/
selinux/<policyname>. or set it to 0 to have them controlled by semanage.
Precaución
Usted no debe cambiar esta valor (0) a menos que sepa con toda certeza el
impacto que dicho cambio conlleva.
44.2.2.2.2. El directorio /etc/selinux/
El directorio /etc/selinux/ es la ubicación predeterminada para todos los archivos de políticas así
como para el principal archivo de configuración.
El siguiente ejemplo muestra contenidos de ejemplo del directorio /etc/selinux/:
-rw-r--r-- 1 root root 448 Sep 22 17:34 c onfig
drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict
drwxr-xr-x 5 root root 4096 Sep 22 17:28 ta rgete d
Los dos subdirectorios, strict/ y targeted/, son los directorios específicos donde los archivos de
políticas del mismo nombre (strict y targeted) se encuentran.
44.2.2.3. Utilidades SELinux
Las siguientes son las utilidades de SELinux más comúnmente usadas:
• /usr/sbin/setenforce — Modifica en tiempo real el modo en que — se ejecuta.
Por ejemplo:
setenforce 1 — SELinux se ejecuta en modo obediente (enforce).
setenforce 0 — SELinux se ejecuta en modo permisivo.
Para desactivar SELinux, necesitará especificar el parámetro setenforce apropiado en /etc/
sysconfig/selinux o pasar el parámetro selinux=0 al kernel, ya sea en /etc/grub.conf o
durante el tiempo de inicio.
• /usr/sbin/sestatus -v — Muestra en detalle el estado de un sistema que está ejecutando
SELinux. El siguiente ejemplo muestra un extracto de la salida de sestatus -v.

737
Recursos adicionales
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Polic y ve rsion: 21
Policy from config file: targeted
Proc ess c onte xts:
Curre nt c onte xt: user_u:syste m_r:unc onfine d_t:s0
Init context: system_u:system_r:init_t:s0
/sbin/mingetty syste m_u:syste m_r:ge tt y_t:s0
• /usr/bin/newrole — Ejecuta una nueva shell en un nuevo contexto o rol. La política debe
permitir la transición al nuevo rol.
Nota
Este comando sólo estará disponiblesi tiene el paquete policycoreutils-
newrole instalado. Esta paquete es requerido por las políticas strict y MLS.
• /sbin/restorecon — Establece el contexto de seguridad de uno o más archivos marcando los
atributos extendidos con el archivo o el contexto de seguridad apropiado.
• /sbin/fixfiles — Revisa o corrige la base de datos de contextos de seguridad en el sistema de
archivos.
Consulte las páginas man relacionadas con estas utilidades para obtener mayor información.
Consulte el contenido de los paquetes setools o policycoreutils para obtener mayor
información sobre las utilidades binarias disponibles. Para ver el contenido de un paquete, utilice el
siguiente comando:
rpm -ql <package-name>
44.2.3. Recursos adicionales
Consulte los siguientes recursos para obtener mayor información sobre SELinux.
44.2.3.1. Documentación instalada
• /usr/share/doc/setools-<version-number>/ All documentation for utilities contained in the
setools package. This includes all helper scripts, sample configuration files, and documentation.
44.2.3.2. Sitios web de interés
• http://www.nsa.gov/research/selinux/index.shtml Homepage for the NSA SELinux development
team. Many resources are available in HTML and PDF formats. Although many of these links are
not SELinux specific, some concepts may apply.
• http://docs.fedoraproject.org/ Homepage for the Fedora documentation project, which contains
Fedora Core specific materials that may be more timely, since the release cycle is much shorter.

738
Recursos adicionales
• http://selinux.sourceforge.net Página principal de la comunidad SELinux.
44.3. Antecedentes e historia de SELinux
SELinux was originally a development project from the National Security Agency (NSA)
1
and others. It
is an implementation of the Flask operating system security architecture.
2
The NSA integrated SELinux
into the Linux kernel using the Linux Security Modules (LSM) framework. SELinux motivated the
creation of LSM, at the suggestion of Linus Torvalds, who wanted a modular approach to security
instead of just accepting SELinux into the kernel.
Originalmente, la implementación SELinux usaba IDs de seguridad persistentes (PSIDs)
almacenados en un campo sin uso en los inodos de ext2. Esta representación numérica (i.e.,
no legible por humanos) eran analizadas por SELinux a una etiqueta de contexto de seguridad.
Desafortunadamente, esto requería la modificación de cada sistema de archivos para soportar PSID,
convirtiéndose así en una solución no escalable o soportada en el desarrollo principal del kernel de
Linux.
The next evolution of SELinux was as a loadable kernel module for the 2.4.<x> series of Linux
kernels. This module stored PSIDs in a normal file, and SELinux was able to support more file
systems. This solution was not optimal for performance, and was inconsistent across platforms.
Finally, the SELinux code was integrated upstream to the 2.6.x kernel, which has full support for LSM
and has extended attributes (xattrs) in the ext3 file system. SELinux was moved to using xattrs to store
security context information. The xattr namespace provides useful separation for multiple security
modules existing on the same system.
Gran parte del esfuerzo requerido para tener el kernel listo para el desarrollo principal, así como
desarrollos subsecuentes de SELinux, ha sido llevado a cabo por NSA, Red Hat y la comunidad de
desarrolladores de SELinux.
For more information about the history of SELinux, the definitive website is http://www.nsa.gov/
research/selinux/index.shtml.
44.4. Multi-Category Security (MCS)
44.4.1. Introducción
Multi-Category Security (MCS) is an enhancement to SELinux, and allows users to label files with
categories. These categories are used to further constrain Discretionary Access Control (DAC) and
Type Enforcement (TE) logic. They may also be used when displaying or printing files. An example
of a category is "Company_Confidential". Only users with access to this category can access files
labeled with the category, assuming the existing DAC and TE rules also permit access.
The term categories refers to the same non-hierarchical categories used by Multi-Level Security
(MLS). Under MLS, objects and subjects are labeled with Security Levels. These Security Levels
consist of a hierarchical sensitivity value (such as "Top Secret") and zero or more non-hierarchical
categories (such as "Crypto"). Categories provide compartments within sensitivity levels and enforce
The NSA is the cryptologic agency of the United Stat es of America's Federal government, charged with information assurance
and signals intelligence. You can read more about the NSA at their website, http://www.nsa.gov/about/.
Flask grew out of a project that integrated the Distributed Trusted Operating System (DTOS) into the Fluke research operating
system. Flask was the name of the architecture and the implementation in the Fluke operating system.

739
Aplicaciones para Seguridad Multi-Categoría
the need-to-know security principle. Refer to Sección 44.6, “Seguridad Multi-Nivel (MLS)” for more
information about Multi-Level Security.
44.4.1.1. ¿Qué es la Seguridad Multi-Categoría?
MCS es una adaptación de MLS. Desde un punto de vista técnico, MCS es un cambio de política
combinado con unas pocas modificaciones para esconder algo de la tecnología MLS innecesaria.
También se hicieron algunos cambios al kernel pero sólo con relación a hacerlo más fácil de actualizar
a MCS (o MLS) sin invocar un re-etiquetamiento de todo el sistema de archivos.
La esperanza es mejorar la calidad del sistema completo, reducir costos, tomar ventaja del proceso
de código abierto, incrementar la transparencia y hacer que la base de la tecnología sea más útil que
sólo para un pequeño grupo de usuarios en casos especiales.
44.4.2. Aplicaciones para Seguridad Multi-Categoría
Más allá del control de acceso MCS también se puede utilizar para presentar las categorias MCS en
la parte superior e inferior de las páginas impresas. Esto también puede incluir una carat de
presentación para indicar los procedimientos de manejo de documentos. También debe ser posible
MCS con desarrollos futuros en SELinux tal como Mejora de Seguridad X. La integración con un
servidor del directorio también hará que el soporte para el correo electrónico sea más fácil. Esto
podría involucrar los uaurios etiquetando de manera manual los correos electrónicos salientes o
adjuntando archivos etiquetados apropiadamente. Después el cliente del correo electrónico puede
determinar si los recipientes pueden acceder las categorías asociadas con los correos electrónicos.
44.4.3. Contextos de Seguridad de SELinux
SELinux stores security contexts as an extended attribute of a file. The "security." namespace is
used for security modules, and the security.selinux name is used to persistently store SELinux
security labels on files. The contents of this attribute will vary depending on the file or directory you
inspect and the policy the machine is enforcing.
Nota
This is expected to change in the 2.6.15 kernel (and already has in the latest -mm
kernels), so that getxattr(2) always returns the kernel's canonicalized version of
the label.
Puede utilizar el comando ls -Z para ver la etiqueta de la categoría de un archivo:
[root@myServer ~]# ls -Z gravityControl.txt
-rw-r--r-- user user user_u:object_r:tmp_t:Moonbase _Pla ns gravityControl.txt
Puede utilizar el comando gefattr(1) para ver el valor de la categoría interna (c10):
[root@myServer ~]# getfattr -n security.selinux gravityControl.txt
# file: gravityControl.txt
security.selinux="user_u:objec t_r:tmp_t:s0:c 10000"
Refer to Sección 44.5, “Getting Started with Multi-Category Security (MCS)” for details on creating
categories and assigning them to files.

740
Aplicaciones para Seguridad Multi-Categoría
44.5. Getting Started with Multi-Category Security (MCS)
This section provides an introduction to using MCS labels to extend the Mandatory Access Control
(MAC) capabilities of SELinux. It discusses MCS categories, SELinux user identities, and how
they apply to Linux user accounts and files. It builds on the conceptual information provided in
Sección 44.4, “Multi-Category Security (MCS)”, and introduces some basic examples of usage.
44.5.1. Introduction
MCS labeling from a user and system administrator standpoint is straightforward. It consists of
configuring a set of categories, which are simply text labels, such as "Company_Confidential" or
"Medical_Records", and then assigning users to those categories. The system administrator first
configures the categories, then assigns users to them as required. The users can then use the labels
as they see fit.
The names of the categories and their meanings are set by the system administrator, and can be set
to whatever is required for the specific deployment. A system in a home environment may have only
one category of "Private", and be configured so that only trusted local users are assigned to this
category.
In a corporate environment, categories could be used to identify documents confidential to specific
departments. Categories could be established for "Finance", "Payroll", "Marketing", and "Personnel".
Only users assigned to those categories can access resources labeled with the same category.
After users have been assigned to categories, they can label any of their own files with any of the
categories to which they have been assigned. For example, a home user in the system described
above could label all of their personal files as "Private", and no service such as Apache or vsftp would
ever be able to access those files, because they don't have access to the "Private" category.
MCS works on a simple principle: to access a file, a user needs to be assigned to all of the categories
with which the file is labeled. The MCS check is applied after normal Linux Discretionary Access
Control (DAC) and Type Enforcement (TE) rules, so it can only further restrict security.
44.5.2. Comparing SELinux and Standard Linux User Identities
SELinux maintains its own user identity for processes, separately from Linux user identities. In the
targeted policy (the default for Red Hat Enterprise Linux), only a minimal number of SELinux user
identities exist:
• system_u — System processes
• root — System administrator
• user_u — All login users
Use the semanage user -l command to list SELinux users:
[root@dhcp-133 ~]# semanage user -l
Labeling MLS/ MLS/
SELinux User
root
Prefix
use r
MCS Level
s0
MCS Range
s0-s0:c0.c 1023
SELinux Roles
system_r sysadm_r use r_r

741
Configuring Categories
system_u use r s0 s0-s0:c0.c 1023 system_r
user_u use r s0 s0-s0:c0.c 1023 system_r sysadm_r use r_r
Refer to Sección 44.8.3, “Usuarios y Roles en la Política Objetivo” for more information about SELinux
users and roles.
SELinux Logins
One of the properties of targeted policy is that login users all run in the same security context. From a
TE point of view, in targeted policy, they are security-equivalent. To effectivly use MCS, however, we
need to be able to assign different sets of categories to different Linux users, even though they are all
the same SELinux user (user_u). This is solved by introducing the concept of an SELinux login. This
is used during the login process to assign MCS categories to Linux users when their shell is launched.
Use the semanage login -a command to assign Linux users to SELinux user identities:
[root@dhcp-133 ~]# semanage login -a james
[root@dhcp-133 ~]# semanage login -a da niel
[root@dhcp-133 ~]# semanage login -a olga
Now when you list the SELinux users, you can see the Linux users assigned to a specific SELinux
user identity:
[root@dhcp-133 ~]# semanage login -l
Login Name SELinux User MLS/MCS Range
default user_u s0
james user_u s0
daniel user_u s0
root root s0-s0:c 0.c 1023
olga user_u s0
Notice that at this stage only the root account is assigned to any categories. By default, the root
account is configured with access to all categories.
Red Hat Enterprise Linux and SELinux are preconfigured with several default categories, but to make
effective use of MCS, the system administrator typically modifies these or creates further categories to
suit local requirements.
44.5.3. Configuring Categories
SELinux maintains a mapping between internal sensitivity and category levels and their human-
readable representations in the setrans.conf file. The system administrator edits this file to
manage and maintain the required categories.
Use the chcat -L command to list the current categories:
[root@dhcp-133 ~]# chcat -L
s0
s0-s0:c0.c1023 SystemLow-Syste mHigh

742
Configuring Categories
s0:c0.c1023 SystemHigh
To modify the categories or to start creating your own, modify the /etc/selinux/<selinuxtype>/
setrans.conf file. For the example introduced above, add the Marketing, Finance, Payroll, and
Personnel categories as follows (this example uses the targeted policy, and irrelevant sections of the
file have been omitted):
[root@dhcp-133 ~]# vi /etc/selinux/targeted/setrans.conf
s0:c0=Marketing
s0:c1=Finance
s0:c 2=Pa yroll
s0:c3=Personnel
Use the chcat -L command to check the newly-added categories:
[root@dhcp-133 ~]# chcat -L
s0:c0 Marketing
s0:c1 Fina nce
s0:c 2 Pa yroll
s0:c 3 Personnel
s0
s0-s0:c0.c 1023 Syst emLow- Syst emHigh
s0:c0.c1023 SystemHigh
Note
After you make any changes to the setrans.conf file, you need to restart the MCS
translation service before those changes take effect. Use the following command to
restart the service:
[root@dhcp-133 ~]# service mcstra ns restart
44.5.4. Assigning Categories to Users
Now that the required categories have been added to the system, you can start assigning them to
SELinux users and files. To further develop the example above, assume that James is in the Marketing
department, Daniel is in the Finance and Payroll departments, and Olga is in the Personnel
department. Each of these users has already been assigned an SELinux login.
Use the chcat command to assign MCS categories to SELinux logins:
[root@dhcp-133 ~]# chcat -l -- +Marketing james
[root@dhcp-133 ~]# chcat -l -- +Finance,+Payroll da nie l
[root@dhcp-133 ~]# chcat -l -- +Personnel olga
You can also use the chcat command with additional command-line arguments to list the categories
that are assigned to users:

743
Assigning Categories to Files
[root@dhcp-133 ~]# chcat -L -l daniel ja mes olga
da niel: Fina nce,Pa yroll
james: Marketing
olga : Personne l
You can add further Linux users, assign them to SELinux user identities and then assign categories to
them as required. For example, if the company director also requires a user account with access to all
categories, follow the same procedure as above:
# Create a use r acc ount for the company director (Karl)
[root@dhcp-133 ~]# useradd karl
[root@dhcp-133 ~]# passwd karl
Changing password for user karl.
New UNIX password:
Retype new UNIX password:
passwd: all authe ntica tion toke ns update d successfully.
# Assign the user account to an SELinux login
[root@dhcp-133 ~]# semanage login -a karl
# Assign all the MCS cate gorie s to the new login
[root@dhcp-133 ~]# chcat -l -- +Marketing,+Finance,+Pa yroll,+Personnel karl
Use the chcat command to verify the addition of the new user:
[root@dhcp-133 ~]# chcat -L -l danie l ja mes olga karl
da niel: Fina nce,Pa yroll
james: Marketing
olga : Personne l
karl: Marketing,Finance,Payroll,Personnel
Note
MCS category access is assigned during login. Consequently, a user does not have
access to newly-assigned categories until they log in again. Similarly, if access to a
category is revoked, this is only apparent to the user after the next login.
44.5.5. Assigning Categories to Files
At this point we have a system that has several user accounts, each of which is mapped to an
SELinux user identity. We have also established a number of categories that are suitable for the
particular deployment, and assigned those categories to different users.
All of the files on the system, however, still fall under the same category, and are therefore accessible
by everyone (but still according to the standard Linux DAC and TE constraints). We now need to
assign categories to the various files on the system so that only the appropriate users can access
them.
For this example, we create a file in Daniel's home directory:
[daniel@dhcp-133 ~]$ echo "Financial Records 2006" > fina nce Rec ords.txt

744
Assigning Categories to Files
Use the ls -Z command to check the initial security context of the file:
[daniel@dhcp-133 ~]$ ls -Z financeRecords.txt
-rw-r--r-- daniel daniel user_u:object_r:user_home_t financeRecords.txt
Notice that at this stage the file has the default context for a file created in the user's home directory
(user_home_t) and has no categories assigned to it. We can add the required category using the
chcat command. Now when you check the security context of the file, you can see the category has
been applied.
[daniel@dhcp-133 ~]$ chcat -- +Finance fina nce Rec ords.txt
-rw-r--r-- da nie l da niel root:object_r:use r_home _t:Fina nce fina nce Re c ords.txt
In many cases, you need to assign more than one category to a file. For example, some files may
need to be accessible to users from both the Finance and Payroll departments.
[daniel@dhcp-133 ~]$ chcat -- +Payroll financeRecords.txt
-rw-r--r-- da niel da nie l root:objec t_r:user_home _t:Fina nce,Pa yroll fina nce Rec ords.txt
Each of the categories that have been assigned to the file are displayed in the security context. You
can add and delete categories to files as required. Only users assigned to those categories can
access that file, assuming that Linux DAC and TE permissions would already allow the access.
If a user who is assigned to a different category tries to access the file, they receive an error message:
[olga@dhcp-133 ~]$ cat fina nce Re c ords.txt
cat: fina nce Rec ords.txt: Pe rmission Denie d
Note
Refer to the man pages for semanage and chcat for more information on the
available options for these commands.
44.6. Seguridad Multi-Nivel (MLS)
Un aspecto vital para muchasempresas es la protección de datos confidenciales y delicados. En el
evento de que tal información senhaga pública, las empresas pueden llegar a enfrentar
consecuencias legales o financieras. Por lo menos sufrirán la pérdida de la confianza de los clientes.
En la mayoría de los casos, se puede recuperar de las pérdidas a nivel financiero y d eotras con una
inversión o una compensación apropiada.
No se puede decir lo mismo de las comunidades de defensa y las relacionadas, las cuales incluyen
los servicios militares, organizaciones de inteligencia y algunasáreas del servicio policial. EStas
organizaciones no se pueden recuperar si se presenta una fuga de información importante y puede
que no se lleguen a recuperar del todo. Estas comunidades requiereen niveles de seguridad más
latos que aquellos empleados por las compañias y otras organizaciones.

745
¿Por qué Multi-Nivel?
El tener información de diferentes niveles de seguridad en el mismo sistema implica una amenaza
real. No es fácil aislar diferentes niveles de seguridad de información aunque los diferentes usuarios
inician sesión urtilizando diferentes cuentas con permisos diferentes y controles de acceso diferentes.
Algunas organizaciones incluso llegan a comprar sistemas especiales para cada nivel de seguridad;
sin embargo, con frecuencia esto es excesivamente costoso. Se requiere un mecanismo para habilitar
a los usuarios en diferentes niveles de seguridad para acceder sistemas de manera simultánea sin el
temor de sufrir contaminación de la información.
44.6.1. ¿Por qué Multi-Nivel?
The term multi-level arises from the defense community's security classifications: Confidential, Secret,
and Top Secret.
Se les debe otorgar a los individuos las autorizaciones apropiadas antes de que puedan ver
información clasificada. Aquellos con autorización confidencial sólamente tienen autorización para
ver documentos confidenciales y no se les permite ver información secreta o reservada. Las reglas
que aplican al flujo de datos operan desde los niveles más bajos a los más latos y nunca de manera
inversa. Esto se encuentra ilustrado a continuación:
Figura 44.2. Niveles de Seguridad de la Información
44.6.1.1. El Modelo Bell-La Padula (BLP)
SELinux como la mayoría de los otros sistemas que protegen datos a multi-nivel, utiliza el modelo
BLP. Este modelo especifica el como debe fluir la información dentro del sistema con base en las
etiquetas de cada sujeto u objeto. Refiérase al siguiente diagrama:

746
¿Por qué Multi-Nivel?
Figura 44.3. Flujos de datos disponibles utilizando un sistema MLS
Under such a system, users, computers, and networks use labels to indicate security levels. Data can
flow between like levels, for example between "Secret" and "Secret", or from a lower level to a higher
level. This means that users at level "Secret" can share data with one another, and can also retrieve
information from Confidential-level (i.e., lower-level), users. However, data cannot flow from a higher
level to a lower level. This prevents processes at the "Secret" level from viewing information classified
as "Top Secret". It also prevents processes at a higher level from accidentally writing information to a
lower level. This is referred to as the "no read up, no write down" model.
44.6.1.2. MLS y Privilegios del Sistema
MLS access rules are always combined with conventional access permissions (file permissions). For
example, if a user with a security level of "Secret" uses Discretionary Access Control (DAC) to block
access to a file by other users, this also blocks access by users with a security level of "Top Secret". A
higher security clearance does not automatically give permission to arbitrarily browse a file system.
Los usuarios con autorizaciones de nivel superior no adquieren automáticamente derechos
administrativos en sistemas multi-nivel. Aunque pueden acceder a toda la información en el
computador, esto es diferente a tener derechos administrativos.
44.6.2. Niveles de Seguridad, Objetos y Sujetos
Como se discutió anteriormente, los sujetos y los objetos tienen etiquetas con Niveles de Seguridad
(NS), los cuales se componen de dos tipos de entidades:
1. Sensitivity: — A hierarchical attribute such as "Secret" or "Top Secret".
2. Categories: — A set of non-hierarchical attributes such as "US Only" or "UFO".

747
Política MLS
Un NS debe tener una sensibilidad y debe tener cero o más categorias.
Ejemplos de NS son: { Secret / UFO, Crypto }, { Top Secret / UFO, Crypto, Stargate } Y { Unclassified }
Note the hierarchical sensitivity followed by zero or more categories. The reason for having categories
as well as sensitivities is so that sensitivities can be further compartmentalized on a need-to-know
basis. For example, while a process may be cleared to the "Secret" sensitivity level, it may not need
any type of access to the project "Warp Drive" (which could be the name of a category).
Nota
1. Los niveles de Seguridad en objetos son llamados Clasificaciones.
2. Los niveles de Seguridad en sujetos son llamados Autorizaciones.
Por lo cual los objetos son etiquetados con una Clasificación, mientras que los
objetos operan con una Autorización específica. Los niveles de seguridad también
pueden tener Rangos, pero estos van más alla de lo que discute esta introducción.
44.6.3. Política MLS
SELinux utiliza el modelo Bell-La Padula BLP con Refuerzo de Tipo (TE) para mantener la integridad.
En términos simples, la política MLS asegura que un Sujeto tenga una autorización apropiada para
acceder un Objeto de una clasificación en particular.
Por ejemplo, bajo MLS, el sistema necesita saber como procesar una petición como: ¿Un proceso
ejecutando con una autorización { Top Secret / UFO, Rail gun } puede escribir en un archivo
clasificado como { Top Secret / UFO } ?
El modelo MLS y la política implementada para esta determinará la respuesta (por ejemplo, considere
una fuga de información de la categoría Rail gun al archivo).
MLS cumple con un grupo de requerimientos de seguridad muy limitado (aunque crítico) con base
en la manera en que se administra la información y el personal en entornos controlados de manera
rígida así como el ejército. Típicamente es dificil trabajar con MLS y no se relacionabien con casos
generales.
El Tipo de Refuerzo (TE) bajo SELinux es un esquema de seguridad más flexible y expresivo , el cual
en muchos casos es más apropiado que MLS.
Sin embargo, hay varios escenarios en donde aún se necesita el tradicional MLS. Por ejemplo, un
servidor de archivos en donde los datos almacenados tengan clasificaciones diferentes y en donde
los clientes se conectan con diferentes autorizaciones. Esto crea un gran número de Niveles de
Seguridad y la necesidad de implementar un aislamiento fuerte en un sistema individual.
El tipo de escenarioes la razón por la cual SELinux incluye MLS como un modelo de seguridad
adjunto a TE.

748
Política MLS
44.6.4. Certificación LSPP
Efforts are being made to have Linux certified as an MLS operating system. The certification is
equivalent to the old B1 rating, which has been reworked into the Labeled Security Protection Profile
3
under the Common Criteria
4
scheme.
44.7. Sinopsis de las Políticas de SELinux
This chapter is an overview of SELinux policy, some of its internals, and how it works. It discusses
the policy in general terms, while Sección 44.8, “Sinopsis de la Política de Objetivos” focuses on the
details of the targeted policy as it ships in Red Hat Enterprise Linux. This chapter starts with a brief
overview of what policy is and where it resides.
A continuación se discutirá el papel de SELinux durante el proceso de arranque seguido por
discusiones sobre contextos de seguridad de archivos, clases de objetos y permisos, atributos,
tipos, vectores de acceso, macros, usuarios y roles, restricciones y un pequeño resumen sobre las
interfaces especiales del kernel.
44.7.1. ¿Qué es la Política SELinux?
La Política SELinux es un grupo de reglas que guian la máquina de seguridad SELinux Define tipos
para objetos de archivos y dominios para procesos. Utiliza roles para limitar los dominios a donde
se puede entrar y tiene identidades de usuario para especificar los roles que se pueden obtener.
Básicamente los tipos y dominios son equivalentes, la diferencia radica en que los tipos aplican a los
objetos mientras que los dominios aplican a los procesos.
44.7.1.1. Tipos de SELinux
A type is a way of grouping items based on their similarity from a security perspective. This is not
necessarily related to the unique purpose of an application or the content of a document. For example,
a file can have any type of content and be for any purpose, but if it belongs to a user and exists in that
user's home directory, it is considered to be of a specific security type, user_home_t.
Estos tipos de objetos se consideran similares ya que son accesibles de la misma manera por el
mismo grupo de sujetos. De manera similar los procesos tienden a ser del mismo tipo si tienen
los mismos permisos que los otros sujetos. En la política objetivo los progarmas que ejecutan
en el dominio unconfined_t tiene un archivo ejecutable con un tipo como sbin_t. Desde una
perspectiva SELinux, estos significa que todos son equivalentes en términos de lo que pueden hacer
y lo que no en el sistema.
Por ejemplo, el objeto del archivo ejecutable binario en /usr/bin/postgres tiene el tipo
postgresql_exec_t. Todos los demonios objetivos tienen su propio tipo *_exec_t para sus
aplicaciones ejecutables. De hecho, el grupo entero de ejecutables PostgreSQL tales como
createlang, pg_dump y pg_restore cuentan con el mismo tipo, postgresql_exec_t y
regresan al mismo dominio, postgresql_t, bajo ejecución.
44.7.1.1.1. Utilización de Reglas de Politicas para Definir Tipo de Acceso
La política SELinux define varias reglas las cuales determinan la manera en que cada dominio
pueda acceder cada tipo. Sólo lo que permiten las reglas es admitido. Por defecto, cada operación
3
http://www.commoncriteriaportal.org/files/ppfiles/lspp.pdf
4
http://www.commoncriteriaportal.org/files/ppfiles/lspp.pdf

749
¿Dónde se encuentra la Política?
es rechazada y auditada lo cual significa que inicia sesión en el archivo $AUDIT_LOG. En Red Hat
Enterprise Linux se encuentra configurado a /var/log/messages. La política es compiladaen
un formato binario para cargar en el servidor de seguridad del kernel y cada vez que el servidor de
seguridad tome una decisión se realiza un caché en el AVC para optimizar el rendimiento.
The policy can be defined either by modifying the existing files or by adding local Type Enforcement
(TE) and File Context (FC) files to the policy tree. These new policies can be loaded into the kernel
in real time. Otherwise, the policy is loaded during the boot process by init, as explained in
Sección 44.7.3, “El Papel de la Política durante el Proceso de Arranque”. Ultimately, every system
operation is determined by the policy and the type-labeling of the files.
Importante
After loading a new policy, it is recommended that you restart any services that may
have new or changed labeling. Generally speaking, this is only the targeted daemons,
as listed in Sección 44.8.1, “¿Qué es la Política Objetivo?”.
44.7.1.2. Control de Acceso Obligatorio y SELinux
SELinux es una implementación de Control de Acceso Obligatorio(MAC). Dependiendo del tipo de
política de seguridad SELinux implementa ya sea Tipo de Reforzamiento (TE), Control de Acceso en
Base a Roles (RBAC) o Seguridad Multinivel Modelo Bell-La Padula (MLS).
La política especifica las reglas en el entorno implementado. Está escrito en un lenguaje creado
específicamente para escribir políticas de seguridad. Escritores de políticas utilizan el macros m4 para
capturar grupos comunes de reglas de bajo nivel. Un número de macros m4 se definen en la política
existente, la cual facilita la escritura de la nueva política. Estas reglas son preprocesadas en muchas
reglas adicionales como parte de la construcción del archivo policy.conf, el cual es compilado en
la política binaria.
Access rights are divided differently among domains, and no domain is required to act as a master
for all other domains. Moving between domains is controlled by the policy, through login programs,
userspace programs such as newrole, or by requiring a new process execution in the new domain.
This movement between domains is referred to as a transition.
44.7.2. ¿Dónde se encuentra la Política?
There are two components to the policy: the binary tree and the source tree. The binary tree is
provided by the selinux-policy-<policyname> package and supplies the binary policy file.
Opcionalmente, la política binaria se puedecontruir desde la fuente cuandose instala el paquete
selinux-policy-devel.
Nota
La información sobre como editar, escribir y compilar políticas se encuentra fuera del
alcance de este documento.
44.7.2.1. Archivos de Arboles Binarios
• /etc/selinux/targeted/ — este es el directorio root para la política objetivo y contiene el árbol
binario.

750
¿Dónde se encuentra la Política?
• /etc/selinux/targeted/policy/ — this is the location of the the binary policy file
policy.<xx>. In this guide, the variable SELINUX_POLICY is used for this directory.
• /etc/selinux/targeted/contexts/ — esta es la ubicación de los archivos de configuración
e información sobre el contexto de seguridad, los cuales son utilizados por varias aplicaciones
durante el tiempo de ejecución.
• /etc/selinux/targeted/contexts/files/ — contiene los contextos predeterminados para
tod el sistema de archivos. Esto es referecniado por restorecon cuando se realizan operaciones
de re-etiquetamiento.
• /etc/selinux/targeted/contexts/users/ — en al política objetivo, sólamente el
archivo root está en este directorio. Estos archivos se utilizan para determinar el contexto
cuando un usuario inicia una sesión. Por ejemplo, para el usuario root el contexto es
user_u:system_r:unconfined_t.
• /etc/selinux/targeted/modules/active/booleans* — aquí es donde se configuran los
valores boleanos en tiempo de ejecución.
Nota
Nunca se deben cambiar estos archivos manualmente. Debe utilizar las
herramientas getsebool, setsebool y semanage para manipular los valores
boleanos en tiempo de ejecución.
44.7.2.2. Archivos de Arboles Fuente
Para desarrolar módulos de políticas, el paquete selinux-policy-devel incluye todos los
archivos de la interfaz utilizados para construir la política. Se recomienda que la gente que construye
políticas utilicen estos archivos para construir los módulos de políticas.
Este apquete instala los archivos de interfaz de políticas bajo /usr/share/selinux/devel/
include y tiene instalados archivos make en /usr/share/selinux/devel/Makefile.
Para ayudar a aplicaciones que necesitan varias rutas SELinux, libselinux proporciona un número
de funciones que devuelven las rutas a los diferentes archivos de configuración y directorios. Esto
invalida la necesidad de que las aplicaciones codifiquen a fuego las rutas especialmente debido a que
la ubicación de la política activa depende de la configuración SELINUXTYPE en /etc/selinux/
config.
Por ejemplo, si SELINUXTYPE es configurado como strict la ubicación de la política activa se
encuentra bajo /etc/selinux/strict.
Para dver la lista de las funciones disponibles utilice el siguiente comando:
man 3 selinux_binary_polic y_pa th

751
El Papel de la Política durante el Proceso de Arranque
Nota
Esta página del manuel se encuentra disponiblesólamente si tiene el RPM
libselinux-devel instalado.
El uso de libselinux y las funciones relacionadas se encuentra fuera del alcance
de este documento.
44.7.3. El Papel de la Política durante el Proceso de Arranque
SELinux tiene un papel importante durante las primeras etapas del arranque del sistema. Debido a
que los procesos deben ser etiquetados con su dominio correcto, init realiza algunas operaciones
esenciales de manera temprana durante el proceso de arranque para mantener la sincronización
entre el etiquetado y el refuerzo de políticas.
1. Después de que se ha cargado el kernel durante el proceso de arranque,se le asigna al proceso
inicial la Identificación inicial SELinux (SID por sus iniciales en inglés) del kernel predefinido. Se
utilizan estos SIDs para bootstrap antes de que se cargue la política.
2. /sbin/init monta /proc/ y después busca el tipo de sistema de archivo selinuxfs. Si está
presente eso quiere decir que SELinux se encuentra activado en el kernel.
3. Si init no encuentra SELinux en el kernel o si se encuentra desactivado por medio del
parámetro boot selinux=0 o si /etc/selinux/config especifica que SELI NUX=disabled
entonces el proceso de arranque procede con un sistema no-SELinux.
At the same time, init sets the enforcing status if it is different from the setting in /etc/
selinux/config. This happens when a parameter is passed during the boot process, such as
enforcing=0 or enforcing=1. The kernel does not enforce any policy until the initial policy is
loaded.
4. Si SELinux se encuentrapresente, se monta /selinux/.
5. init checks /selinux/policyvers for the supported policy version. The version number in
/selinux/policyvers is the latest policy version your kernel supports. init inspects /etc/
selinux/config to determine which policy is active, such as the targeted policy, and loads the
associated file at $SELINUX_POLICY/policy.<version>.
Si la política binaria no es la versión soportada por el kernel entonces init intenta cargar el
archivo de políticas si es una versión anterior. Esto proporcina una compatibilidad retroactiva con
versiones de políticas previas.
Si la configuración local en /etc/selinux/targeted/booleans es diferente de la compilada
en la política entonces init modifica la política en la memoria con base en la configuración local
antes de cargar la política en el kernel.
6. En este punto del proceso, la política se encuentra completamentecargada en el kernel. Luego
los SIDs iniciales son mapeados a los contextos de seguridad en la política. En el caso de la
política objetivo el nuevo dominio es user_u:system_r:unconfined_t. Ahora el kernel puede
empezar a recuperar contextos de seguridad dinámicamente desde el servidor de seguridad que
se encuentra en el kernel.

752
El Papel de la Política durante el Proceso de Arranque
7. Después init se re-ejecutaa sí mismo para que pueda regresar a un dominio diferente si al
política lo define. Para la política objetivo no hay una transición definida y init permanece en el
dominio unconfined_t.
8. En este punto, init continua con su proceso normal de arranque.
The reason that init re-executes itself is to accommodate stricter SELinux policy controls. The
objective of re-execution is to transition to a new domain with its own granular rules. The only way that
a process can enter a domain is during execution, which means that such processes are the only entry
points into the domains.
Por ejemplo, si la política ha especificado un dominio para init, tal como init_t se neceista
un método para cambiar el SID inicial así como kernel al dominio de tiempo de ejecución correcto
para init. Debido a que puede necesitarse que ocurra esta transición, init es codificado para re-
ejecutarse a si mismo después de cargar la política.
This init transition occurs if the domain_auto_trans(kernel_t, init_exec_t,
<target_domain_t>) rule is present in the policy. This rule states that an automatic transition
occurs on anything executing in the kernel_t domain that executes a file of type init_exec_t. When
this execution occurs, the new process is assigned the domain <target_domain_t>, using an
actual target domain such as init_t.
44.7.4. Clases de Objetos y Permisos
SELinux define un número de calses para objetos haciendo más fácil agrupar ciertos permisos de
acuerdo con clases especificas. Por ejemplo:
• Clases relacionadas con archivos incluyen filesystem para sistemas de archivos, file para
archivos y dir para directorios. Cada clase tiene su propio grupo de permisos asociados.
La clase filesystem puede montar, desmontar, obtener atributos, establecer cuotas, re-etiquetar,
etc. La clase file tiene permisos de archivos comúnes lectura, escritura, obtener y configurar
atributos, bloquear, re-etiquetar, enlazar, renombrar, añadir, etc.
• Las clases realcionadas con la red incluyen tcp_socket para sockets TCP, netif para interfaces
de red y node para nodos de red.
Por ejemplo, la clase netif puede enviar y recibir en TCP, UDP y sockets raw (tcp_recv,
tcp_send, udp_send,udp_recv, rawip_recv y rawip_send).
Las clases de objetos tiene declaraciones que coinciden en el kernel lo cual significa que no es nada
trivial el añadir o cambiar detalles a las clases de objetos. Lo mismo aplica para permisos. El trabajo
de desarrollo es continuo y hace posible registrar y sacar del registro dinámicamenteclases y
permisos.
Los permisos son acciones que un sujeto puede realizar en un objeto si la política lo permite. Estos
permisos son las peticiones de acceso que SELinux permite o rechaza activamente.
44.8. Sinopsis de la Política de Objetivos
Este capítulo es una sinopsis y examen de la política de objetivos de SELinux, la política actual
soportada para Red Hat Enterprise Linux.

753
¿Qué es la Política Objetivo?
Mucho del contenido de este capítulo se aplica a todos los tipos de políticas de SELinux en términos
de ubicación de archivos y el tipo de contenido en esos archivos. La diferencia radica en los archivos
que existen en lugares clave y su contenido.
44.8.1. ¿Qué es la Política Objetivo?
The SELinux policy is highly configurable. For Red Hat Enterprise Linux 5, Red Hat supports
a single policy, the targeted policy. Under the targeted policy, every subject and object runs in
the unconfined_t domain except for the specific targeted daemons. Objects that are in the
unconfined_t domain have no restrictions and fall back to using standard Linux security, that is,
DAC. The daemons that are part of the targeted policy run in their own domains and are restricted in
every operation they perform on the system. This way daemons that are exploited or compromised in
any way are contained and can only cause limited damage.
Por ejemplo, los demonios http y ntp están protegidos en la política objetivo predeterminada y
ejecutan en los dominios httpd_t y ntpd_t, respectivamente. Sin embargo, el demonio ssh no está
protegido en esta política y por consecuencia ejecuta en el dominio unconfined_t.
Refiérase a la siguiente salida de ejemplo, la cual ilustra los diversos dominios para los demonios
mencionados anteriormente:
user_u:syste m_r:httpd_t 25129 ?00:00:00 httpd
user_u:syste m_r:ntpd_t 25176 ? 00:00:00 ntpd
system_u:system_r:unconfined_t 25245 ? 00:00:00 sshd
La Política Estricta
The opposite of the targeted policy is the strict policy. In the strict policy, every subject and object
exists in a specific security domain, and all interactions and transitions are individually considered
within the policy rules.
La política estricta es un entorno mucho más complejo y no se envía junto con Red Hat Enterprise
Linux. Este manual se encfoca en la política objetivo que se entrega junto con Red Hat Enterprise
Linux y los componentes de SELinux utilizados por los demonios objetivo.
Los demonios objetivos son los siguientes:dhcpd; httpd; mysqld; named; nscd; ntpd; portmap;
postgres; snmpd; squid; syslogd y winbind.
Nota
Dependiendo de su instalación sólamente algunos de estos demonios pueden llegar
a estar presentes.
44.8.2. Archivos y Directorios de la Política Objetivo
Refer to Sección 44.7.2, “¿Dónde se encuentra la Política?” for a list of the common files and
directories used by SELinux.
44.8.3. Usuarios y Roles en la Política Objetivo
Esta sección cubre los rroles específicos activados para la política objetivo.

754
Effectively, there are only two roles in the targeted policy: system _r and object_r. The initial role
is system_r, and everything else inherits that role. The remaining roles are defined for compatibility
purposes between the targeted policy and the strict policy.
5
Tres de los cuatro roles están definidos por la política. El cuarto rol object_r, es un rol supuesto y
no se encuentra en la fuente de políticas. Debido a que los roles son creado y completados por tipos
utilizando una o más declaraciones en la política, no hay un solo archivo que declare todos los roles
(recuerde que la política misma es generada de un número de archivos separados).
system_r
El rol es para todos los procesos del sistema a excepción de los procesos del usuario:
system_r (28 types)
dhcpd_t
httpd_helper_t
httpd_php_t
httpd_suexec_t
httpd_sys_sc ript_t
httpd_t
httpd_unc onfine d_script_t
initrc_t
ldc onfig_t
mailman_cgi_t
mailman_mail_t
mailman_queue_t
mysqld_t
named_t
ndc_t
nscd_t
ntpd_t
pegasus_t
portmap_t
postgresql_t
snmpd_t
squid_t
syslogd_t
system_mail_t
unconfined_t
winbind_helper_t
winbind_t
ypbind_t
user_r
Este es el rol de usuario predeterminado para usuarios de Linux habilutales. En una política
estricta, los usuarios individuales pueden llegar a utilizarse, permitiendo a los usuarios tener roles
especiales para realizar operaciones privilegiadas. En la política de objetivos todos los usuarios
ejecutan en el dominio unconfined_t.
object_r
En SELinux, los roles no se utilizan para objetos cuando RBAC se está utilizando. LOs roles son
estrictamente para sujetos. Esto se debe a que los roles son orientados a tareas y agrupan
entidades las cuales relaizan acciones (por ejemplo, procesos). Todas estas entidades son
referidas colectivamente como sujetos. Por esta razón todos los objetos tienen el rol object_r y
el rol solo se utiliza como un parámetro de sustitución en la etiqueta.
Any role could have been chosen for the targeted policy, but system_r already had existing authorization for the daemon
domains, simplifying the process. This was done because no mechanism currently exists to alias roles.

755
sysadm_r
Este es el rol del administrador del sistema en una política estricta. Si inicia la sesión
directamente como usuario root el rol predeterminado puede ser de hecho staff_r. Si
es verdadero utilice el comando newrole -r sysadm_r para cambiar al rol del
administrador del sistema de SELinux para realizar tareas de administración del sistema.
En la política de objetivos los siguinetes retienen sysadm_r pr compatibilidad:
sysadm_r (6 types)
httpd_helper_t
httpd_sys_sc ript_t
initrc_t
ldc onfig_t
ndc_t
unconfine d_t
There is effectively only one user identity in the targeted policy. The user_u identity was
chosen because libselinux falls back to user_u as the default SELinux user identity.
This occurs when there is no matching SELinux user for the Linux user who is logging in.
Using user_u as the single user in the targeted policy makes it easier to change to the strict
policy. The remaining users exist for compatibility with the strict policy.
6
The one exception is the SELinux user root. You may notice root as the user identity in a
process's context. This occurs when the SELinux user root starts daemons from the
command line, or restarts a daemon originally started by init.
A user aliasing mechanism would also work here, to alias all identities from the strict policy to a single user
identity in the target ed policy.

44 seguridad y se linux

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (13)

Destacado

Destacado (9)

Similar a 44 seguridad y se linux

Similar a 44 seguridad y se linux (20)

Más de Aprende Viendo

Más de Aprende Viendo (19)

Último

Último (20)

44 seguridad y se linux