44 seguridad y se linux
TRANSCRIPT
731
Seguridad y SELinux
44.1. Mecanismos de Control de Acceso (ACMs) Esta sección proporc iona una introducc ión bás ic a a los Mecanismos de Control de Acceso (ACMs).
Los ACMs proporc ionan un medio para los administradores de s is temas para controlar que usuarios
y que porc esos pueden acc eder a diferentes archivos, disos itivos, interfaces, etc, en un sistema de
computador. Es una de las cons iderac iones princ ipales al asegurar un sis tema 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 proporc ionan los permisos de arc hivos, etc. Tal
acc eso se enc entra generalmente a la discrec ió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 acc ess those objec ts. Depending on a subjec t's acc ess permiss ions, they may
also be able to pass permiss ions to other subjec ts.
44.1.2. Control de Acceso Mandatorio (MAC)
El Control de Acceso Mandatorio (MAC) es un mec anismo de seguridad que res tr inge el nivel de
control que los usuarios (sujetos) tienen sobre otros objetos que crean. DE manera opuesta que
en una implementac ión DAC, en donde los usuarios tienen control total sobre sus propios archivos,
directorios, etc, MAC añade etiquetas adic ionales o categorías a todos los objetos del sistema de
archivos. Los usuarios y los proc esos tienen que tener el acc eso apropiado a estas c ategorias antes
de que puedan interactuar con estos objetos.
In Red Hat Enterprise Linux, MAC is enforc ed 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 s is tema de archivos. En vez de que los permisos de usuario controlen
el acceso, el administrador del s istema establec e Roles basados en requeriemeintos func ionales
empresariales o un criterio similar. Estos Roles tienen diferentes tipos y distintos niveles de acceso a
objetos.
In contras t to DAC or MAC systems, where users have access to objects based on their own and the
object's permiss ions, users in an RBAC system must be members of the appropriate group, or Role,
before they can interact with files, directories, devic es, etc.
Desde un punto de vista administrativo, esto hace mucho más fácil controlar quienes tienen acceso a
varias partes del s istema de archivos con tan sólo controlar sus mermbresías a grupos.
732
Archivos relac ionados 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 Subjec ts. Files, sockets and other pass ive operating sys tem 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 agenc ia de seguridad de los
Es tados Unidos (NSA) y la comunidad SELinux. La integrac ió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 applic ation or proc ess running as a user (UID
or SUID) has the user's permiss ions to objects such as files, soc kets, and other processes. Running a
MAC kernel protects the sys tem from malicious or flawed applications that can damage or destroy the
system.
SELinux define los derec hos de acceso y transmis ión de cada usuario, aplic ac ión, proc eso y archivo
en el s is tema. SELinux gobierna luego la interacc ión de estas entidades mediante el uso de polític as
de seguridad que espec if ican qué tan estricto debe ser una instalac ión de Red Hat Enterprise Linux.
Diariamente, los usuarios del s istema no son conc ientes de la presenc ia de SELinux. Sólo los
administradores de s is temas nec es itan c ons iderar qué tan estr icta debe ser la política implementada
en los entornos de los servidores. Las políticas pueden ser tan estr ic tas o indulgentes como sea
nec esario. Las políticas son bastante detalladas, lo cual proporc iona un control detallado y completo
del kernel de SELinux sobre el s istema entero.
El proceso de toma de decisiones de SELinux
When a subject, (for example, an applic ation), attempts to access an object (for example, a file), the
policy enforc ement server in the kernel chec ks an access vector cache (AVC), where subjec t and
object permiss ions are cac hed. If a dec is ion cannot be made based on data in the AVC, the reques t
continues to the security server, which looks up the security context of the application and the file in a
matrix. Permiss ion is then granted or denied, with an avc: denied message detailed in /var/log/
messages i f permiss ion is denied. The security context of subjec ts and objects is applied from the
installed policy, which also provides the information to populate the security server's matrix.
Consulte el s iguiente diagrama:
733
Archivos relac ionados con SELinux
Figura 44.1. Proc eso de dec is ión de SELinux
Modos de ope ración de SELinux
En vez de ejec utarse en el modo obediente, SELinux puede ejec utarse en el modo permisivo, en
donde el AVC es revisado y las negac iones son regis tradas sin que SELinux aplique la política. Es ta
propiedad es útil durante el periodo de soluc iones 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. Arc hivos relaciona dos con SELinux
Las siguientes secc iones desc riben los archivos de configurac ión de SELinux y los sistemas de
arc hivos relac ionados.
44.2.2.1. El seudo sistema de archivos de SELinux
El seudo s is tema de archivos /selinux/ contiene c omandos que son utilizados por el subs is tema
del kernel. Esta clase de s istema de arc hivos es similar al seudo s istema de archivos /proc/.
Ni los administradores ni los usuarios nec es itan normalmente manipular es te c omponente.
El s iguiente ejemplo muestra c ontenidos 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
Archivos relac ionados con SELinux
-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 ejec utar el comando cat en el archivo enforce revela 1 para el modo obediente o 0
para el modo permis ivo.
44.2.2.2. Archivos de configuración de SELinux
Las siguientes secc iones desc riben los archivos de políticas y configurac ión de SELinux y los
s istemas de archivos relac ionados 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 f ile (/etc/
sysconfig/selinux).
El archivo /etc/sysconfig/selinux es el archivo de configurac ión principal para activar o
desactivar SELinux. También permite establec er la política a cumplir y la forma en que ésta debe ser
seguida.
Nota
El archivo /etc/sysconfig/selinux es un enlac e simbólico al archivo de
configurac ión /etc/selinux/config .
A continuac ión se muestran los grupos de opc iones disponibles para la configurac ión:
• SELINU X=enforcing|permissive|disabled — Define el estado principal de SELinux en un
s istema.
• enforcing (obediente) — La política de seguridad de SELinux entra en vigor.
• permissive (permis iva) — El s is tema SELinux crea advertenc ias pero no aplica la polític a.
Esta opción es útil durante la depurac ión y solución de errores. En el modo permisivo, muchas
más negac iones 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: denied por cada nivel del directorio que
sea leído. En modo obediente, SELinux detendría la explorac ión inicial evitando así la oc urrenc ia
de más mensajes de negac ión.
• disabled (deshabilitado) — SELinux es c ompletamente desactivado. Los enlaces de SELinux
son desprendidos del kernel y se borra el registro del seudo s is tema de archivos.
735
Archivos relac ionados con SELinux
Tip
Las acc iones que son ejecutadas mientras SELinux es tá desactivado pueden
resultar en la perdida de los contextos de seguridad c orrec tos 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 proc eso de arranque, antes
de que cualquier servicio es te s iendo ejec utado en el s istema. Al usar este
proc edimiento se asegura que ningún proc eso cree accidentalmente archivos
con un contexto erróneo o sean iniciados en un contexto erróneo.
Es posible utilizar el c omando fixfiles relabel antes de activar SELinux
para etiquetar el s istema de arc hivos. Este método no es rec omendado porque
es posible que algunos proc esos permanezc an en ejec uc ión dentro del contexto
erróneo después de que el comando ha etiquetado el s istema de archivos. Estos
proc esos podrían crean arc hivos que también es tarían en un contexto erróneo.
Nota
Espac ios en blanco adic ionales al final de las líneas de configurac ión o como
líneas extras al final del archivo pueden c ausar c omportamientos inesperados. Por
seguridad, remueva los espac ios en blanco que no sean necesarios.
• SELINUXTYPE=targeted|strict — Espec if ica la política que debe ser aplic ada 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), name d, nscd, ntpd,
portmap, snmpd, squid y syslogd. El resto del sistema se ejecuta en el
dominio unc onfined_t. Este dominio le permite a los sujetos y objetos con este
contexto de seguridad operar utilizando la seguridad es tándar de Linux.
Los archivos de políticas para esos demonios es tán en /etc/selinux/
targeted/src/policy/domain/program. Estos arc hivos están sujetos a
cambios en las nuevas vers iones de Red Hat Enterprise Linux.
Policy enforc ement 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 establec er un booleano de
736
Archivos relac ionados con SELinux
SELinux. La opción -P hace que el cambio sea permanente. Si esta opción no se espec if ic a, el
valor booleano regresará a 1 durante el inicio del s istema.
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 ejecuc ión de polític as.
• 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 c ambiar 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 ubic ac ión predeterminada para todos los archivos de políticas así
como para el principal archivo de configurac ión.
El s iguiente ejemplo muestra c ontenidos 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íf ic os 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 (enforc e).
setenforce 0 — SELinux se ejecuta en modo permis ivo.
Para desac tivar SELinux, nec es itará espec if ic ar 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 s iguiente ejemplo muestra un extracto de la salida de sestatus -v.
737
Rec ursos adic ionales
SELin ux 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 sys te m_u:syste m_r:ge tty_t:s0
• /usr/bin/newrole — Ejec uta una nueva shell en un nuevo contexto o rol. La política debe
permitir la trans ic ión al nuevo rol.
Nota
Este comando sólo estará disponible s i tiene el paquete policycoreutils-
newrole instalado. Esta paquete es requerido por las políticas strict y MLS.
• /sbin/restorecon — Establec e el contexto de seguridad de uno o más archivos marc ando los
atr ibutos 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 relac ionadas 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 s iguientes rec ursos 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 pac kage. This inc ludes 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 resourc es are available in HTML and PDF formats. Although many of these links are
not SELinux specific, some c onc epts may apply.
• http://docs.fedoraproject.org/ Homepage for the Fedora doc umentation project, which contains
Fedora Core specific materials that may be more timely, since the release cycle is much shorter.
738
Rec ursos adic ionales
• 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 sys tem security architecture.2The 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 approac h to security
ins tead of just accepting SELinux into the kernel.
Originalmente, la implementac ión SELinux usaba IDs de seguridad persistentes (PSIDs)
almac enados en un campo sin uso en los inodos de ext2. Esta representac ión numéric a ( 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 s istema 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
sys tems. This solution was not optimal for performance, and was inc ons istent 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 namespac e provides useful separation for multiple security
modules existing on the same sys tem.
Gran parte del esfuerzo requerido para tener el kernel listo para el desarrollo principal, así como
desarrollos subsec uentes 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 webs ite is http://www.nsa.gov/
research/selinux/index.shtml.
44.4. Multi-Category Security (MCS)
44.4.1. Intro ducción
Multi-Category Security (MCS) is an enhanc ement to SELinux, and allows users to label files with
categories. These c ategories 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 acc ess f iles
labeled with the category, assuming the existing DAC and TE rules also permit access.
The term categories refers to the same non-hierarchic al categories used by Multi-Level Security
(MLS). Under MLS, objec ts and subjec ts are labeled with Security Levels. These Security Levels
cons ist 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 enforc e
The NSA is the cryptologic agen cy of the United Stat es of Amer ica's Federal govern ment, ch arged with information assuran ce
and signals intelligence. You can read more about the NSA at their website, http://www.n sa.go v/about/.
Flask grew out of a project that integrated the Distributed Trusted Operating System (DTOS) into the Fluke research operatin g
sy stem. Flask was the name of the architecture and the implementation in the Fluke operatin g system.
739
Aplic aciones 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 adaptac ión de MLS. Desde un punto de vista técnico, MCS es un cambio de política
combinado con unas pocas modific ac iones para esc onder algo de la tecnología MLS innec esaria.
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 s istema completo, reducir costos, tomar ventaja del proc eso
de código abierto, incrementar la transparenc ia y hac er que la base de la tec nologí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
presentac ión para indicar los procedimientos de manejo de documentos. También debe ser pos ible
MCS con desarrollos futuros en SELinux tal como Mejora de Seguridad X. La integrac ión con un
servidor del directorio también hará que el soporte para el correo electrónic o sea más fácil. Esto
podría involucrar los uaurios etiquetando de manera manual los correos elec trónic os salientes o
adjuntando arc hivos etiquetados apropiadamente. Después el cliente del correo electrónico puede
determinar si los rec ipientes pueden acceder las categorías asoc iadas con los correos electrónic os.
44.4.3. Contextos de Segurida d de SELinux
SELinux stores security contexts as an extended attribute of a file. The "security." namespac e 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 enforc ing.
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 canonic alized version of
the label.
Puede utilizar el comando ls -Z para ver la etiqueta de la c ategorí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 10\000"
Refer to Sección 44.5, “Getting Started with Multi-Category Security (MCS)” for details on creating
categories and ass igning them to files.
740
Aplic aciones 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 introduc es some bas ic examples of usage.
44.5.1. Intro duction
MCS labeling from a user and system administrator standpoint is straightforw ard. It cons ists of
configuring a set of categories, which are simply text labels, such as "Company_Confidential" or
"Medic al_Records", and then ass igning users to those c ategories. 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 ass igned to this
category.
In a corporate environment, c ategories could be used to identify documents confidential to spec if ic
departments. Categories could be established for "Finance", "Payroll", "Marketing", and "Personnel".
Only users assigned to those c ategories can acc ess resourc es labeled with the same category.
After users have been ass igned to c ategories, they can label any of their own files with any of the
categories to which they have been ass igned. For example, a home user in the system described
above could label all of their personal f iles as "Private", and no service such as Apac he 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 ass igned to all of the categories
with which the file is labeled. The MCS check is applied after normal Linux Discretionary Acc ess
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 proc esses, 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 — Sys tem processes
• root — System administrator
• user_u — All login users
Use the semanage user -l c ommand to list SELinux users :
[root@dhcp-133 ~]# semanage user -l
Labeling MLS/ MLS/ SELinux User
root
Pref ix
use r
MCS Level
s0
MCS Ran ge
s0-s0:c0.c 1023
SELin ux 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, w e
need to be able to ass ign 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 proc ess to ass ign MCS categories to Linux users when their shell is launched.
Use the semanage login -a command to ass ign 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 SELin ux User MLS/MCS Ran ge
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 ass igned to any categories. By default, the root
account is configured with access to all c ategories.
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 c ategories.
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 introduc ed above, add the Marketing, Finance, Payroll, and
Personnel c ategories 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 Sy st em Lo w- Sy st em High
s0:c0.c1023 SystemHigh
Note
After you make any changes to the setrans.conf f ile, you need to restart the MCS
trans lation servic e before those c hanges take effect. Use the following command to
res tart the servic e:
[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 ass igned an SELinux login.
Use the chcat command to ass ign 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 ass igned 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, ass ign them to SELinux user identities and then ass ign categories to
them as required. For example, if the company director also requires a user acc ount with access to all
categories, follow the same proc edure as above:
# Create a use r acc ount for the co mp any 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 acc ess is ass igned during login. Consequently, a user does not have
access to new ly-ass igned c ategories 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 acc ounts, eac h 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 ass igned those c ategories to different users.
All of the files on the system, how ever, still fall under the same c ategory, and are therefore acc ess ible
by everyone (but still according to the standard Linux DAC and TE constraints). We now need to
ass ign c ategories 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 ass igned to it. We can add the required c ategory using the
chcat c ommand. 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
[daniel@dhcp-133 ~]$ ls -Z financeRecords.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 ass ign more than one category to a file. For example, some files may
need to be access ible to users from both the Financ e and Payroll departments.
[daniel@dhcp-133 ~]$ chcat -- +Payroll financeRecords.txt
[daniel@dhcp-133 ~]$ ls -Z 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 ass igned to the file are displayed in the security context. You
can add and delete c ategories to files as required. Only users assigned to those c ategories c an
access that file, assuming that Linux DAC and TE permiss ions would already allow the access.
If a user who is ass igned to a different category tr ies to access the file, they receive an error message:
[olga@dhcp-133 ~]$ cat f ina nce Re c ords. txt
cat: fina nce Rec ords.txt: Pe rmission Den ie d
Note
Refer to the man pages for semanage and chcat for more information on the
available options for these c ommands.
44.6. Seguridad Multi-Nivel (MLS) Un aspec to vital para muchas empresas es la protección de datos confidenc iales y delic ados. En el
evento de que tal información senhaga pública, las empresas pueden llegar a enfrentar
consec uenc ias legales o f inanc ieras. Por lo menos sufrirán la pérdida de la confianza de los clientes.
En la mayoría de los casos, se puede rec uperar de las pérdidas a nivel financiero y d eotras con una
inversión o una compensac ión apropiada.
No se puede decir lo mismo de las comunidades de defensa y las relac ionadas, las cuales inc luyen
los servic ios militares, organizac iones de inteligenc ia y algunas áreas del servicio policial. EStas
organizac iones no se pueden rec uperar 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 organizac iones.
745
¿Por qué Multi-Nivel?
El tener información de diferentes niveles de seguridad en el mismo s istema implica una amenaza
real. No es fácil aislar diferentes niveles de seguridad de información aunque los diferentes usuarios
inician ses ión urtilizando diferentes cuentas con permisos diferentes y controles de acc eso diferentes.
Algunas organizac iones incluso llegan a comprar s istemas espec iales para cada nivel de seguridad;
sin embargo, con frecuenc ia esto es exc es ivamente c ostoso. Se requiere un mecanismo para habilitar
a los usuarios en diferentes niveles de seguridad para acc eder s is temas de manera s imultánea sin el
temor de sufrir contaminac ión de la informac ión.
44.6.1. ¿Por qué Multi-Nivel?
The term multi-level arises from the defense c ommunity's security class if ications : Confidential, Secret,
and Top Secret.
Se les debe otorgar a los individuos las autorizac iones apropiadas antes de que puedan ver
información clas if icada. Aquellos con autorizac ión confidencial sólamente tienen autorizac ión para
ver documentos confidenc iales 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 nunc a de manera
inversa. Esto se encuentra ilustrado a continuac ió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 espec if ic a 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 s istema MLS
Under such a system, users, c omputers, and networks use labels to indicate security levels. Data can
flow betw een like levels, for example betw een "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 retr ieve
information from Confidential- level ( i.e., lower-level), users. However, data cannot flow from a higher
level to a lower level. This prevents proc esses at the "Secret" level from viewing information class if ied
as "Top Secret". It also prevents proc esses 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 acc ess permiss ions (file permiss ions). For
example, i f a user with a security level of "Secret" uses Discretionary Acc ess 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 clearanc e does not automatically give permiss ion to arbitrarily browse a file sys tem.
Los usuarios con autorizac iones de nivel superior no adquieren automátic amente derec hos
adminis trativos en s is temas multi-nivel. Aunque pueden acc eder a toda la información en el
computador, esto es diferente a tener derec hos 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 c omponen de dos tipos de entidades :
1. Sensitivity: — A hierarchical attr ibute such as "Secret" or "Top Secret".
2. Categories: — A set of non-hierarchic al attr ibutes such as "US Only" or "UFO".
747
Política MLS
Un NS debe tener una sens ibilidad y debe tener cero o más categorias.
Ejemplos de NS son: { Secret / UFO, Crypto }, { Top Secret / UFO, Crypto, Stargate } Y { Unc lassif ied }
Note the hierarchic al sensitivity followed by zero or more categories. The reason for having categories
as well as sens itivities is so that sensitivities can be further compartmentalized on a need-to-know
bas is. For example, while a proc ess 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 Clas if ic ación, mientras que los
objetos operan con una Autorización específ ic a. Los niveles de seguridad también
pueden tener Rangos, pero estos van más alla de lo que disc ute es ta introducc ió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 s imples, la política MLS asegura que un Sujeto tenga una autorizac ión apropiada para
acc eder un Objeto de una clas if icación en particular.
Por ejemplo, bajo MLS, el sistema nec es ita saber como proc esar una petición como: ¿Un proc eso
ejec utando con una autorizac ión { Top Secret / UFO, Rail gun } puede escribir en un archivo
clas if icado como { Top Sec ret / UFO } ?
El modelo MLS y la política implementada para esta determinará la respuesta (por ejemplo, cons idere
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ípic amente es dif icil trabajar con MLS y no se relac iona bien con casos
generales.
El Tipo de Refuerzo (TE) bajo SELinux es un esquema de seguridad más flexible y expres ivo , el cual
en muc hos c asos es más apropiado que MLS.
Sin embargo, hay varios esc enarios en donde aún se necesita el tradicional MLS. Por ejemplo, un
servidor de archivos en donde los datos almac enados tengan c las if ic ac iones diferentes y en donde
los clientes se c onectan con diferentes autorizac iones. Esto crea un gran número de Niveles de
Seguridad y la nec es idad de implementar un ais lamiento fuerte en un sistema individual.
El tipo de escenario es 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 rew orked into the Labeled Security Protection Profile3
under the Common Criteria4
sc heme.
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 res ides.
A continuac ión se discutirá el papel de SELinux durante el proc eso de arranque seguido por
disc us iones sobre c ontextos de seguridad de archivos, c lases de objetos y permisos, atr ibutos,
tipos, vectores de acc eso, macros, usuarios y roles, restr icc iones y un pequeño resumen sobre las
interfac es espec iales 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 proc esos. Utiliza roles para limitar los dominios a donde
se puede entrar y tiene identidades de usuario para espec if ic ar los roles que se pueden obtener.
Bás ic amente los tipos y dominios son equivalentes, la diferenc ia radica en que los tipos aplican a los
objetos mientras que los dominios aplican a los proc esos.
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 cons idered to be of a specific security type, user_home_t.
Estos tipos de objetos se cons ideran s imilares ya que son acc es ibles de la misma manera por el
mismo grupo de sujetos. De manera similar los proc esos tienden a ser del mismo tipo si tienen
los mismos permisos que los otros sujetos. En la política objetivo los progarmas que ejec utan
en el dominio unconfined_t tiene un archivo ejec utable con un tipo como sbin_t. Desde una
perspectiva SELinux, estos significa que todos son equivalentes en términos de lo que pueden hac er
y lo que no en el sistema.
Por ejemplo, el objeto del archivo ejec utable binario en /usr/bin/postgres tiene el tipo
postgresql_exec _t. Todos los demonios objetivos tienen su propio tipo *_exec_t para sus
aplic ac iones ejec utables. De hecho, el grupo entero de ejec utables Postgre SQL tales como
createlang, pg_dump y pg_restore c uentan con el mismo tipo, postgresql_exec_t y
regresan al mismo dominio, postgresql_t, bajo ejecuc ió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 acc eder c ada tipo. Sólo lo que permiten las reglas es admitido. Por defecto, c ada operac ión
3 http://www.commoncr iteriaportal.org/files/ppfiles/lspp.pdf
4 http://www.commoncr iteriaportal.org/files/ppfiles/lspp.pdf
749
¿Dónde se encuentra la Polític a?
es rechazada y auditada lo cual signif ica que inicia ses ión en el archivo $AUDIT_LOG. En Red Hat
Enterprise Linux se enc uentra c onfigurado a /var/log/messages. La política es compilada en
un formato binario para cargar en el servidor de seguridad del kernel y cada vez que el servidor de
seguridad tome una dec is ió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. Otherw ise, the policy is loaded during the boot proc ess 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 servic es 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 implementac ió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 espec if ica las reglas en el entorno implementado. Está escrito en un lenguaje creado
específ ic amente para escribir políticas de seguridad. Escritores de políticas utilizan el mac ros m4 para
capturar grupos c omunes 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 preproc esadas en muc has
reglas adic ionales como parte de la construcc ión del archivo policy.conf, el cual es compilado en
la política binaria.
Acc ess r ights are divided differently among domains, and no domain is required to act as a master
for all other domains. Moving betw een domains is controlled by the policy, through login programs,
userspac e programs such as newrole, or by requiring a new proc ess execution in the new domain.
This movement betw een 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 sourc e tree. The binary tree is
provided by the selinux-policy-<policyname> pac kage and supplies the binary policy file.
Opc ionalmente, la política binaria se puede contruir desde la fuente cuando se instala el paquete
selinux-policy-devel.
Nota
La información sobre como editar, escribir y compilar políticas se encuentra fuera del
alc anc e de es te doc umento.
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ític a?
• /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 ubicac ión de los archivos de configurac ión
e información sobre el contexto de seguridad, los cuales son utilizados por varias aplic ac iones
durante el tiempo de ejecuc ión.
• /etc/selinux/targeted/contexts/files/ — contiene los contextos predeterminados para
tod el s is tema de archivos. Esto es referec niado por restorecon c uando se realizan operac iones
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 ses ió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 ejecuc ión.
Nota
Nunca se deben c ambiar es tos arc hivos manualmente. Debe utilizar las
herramientas getsebool, setsebool y se manage para manipular los valores
boleanos en tiempo de ejecuc ió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 arc hivos para construir los módulos de polític as.
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 aplic ac iones que nec es itan varias rutas SELinux, libselinux proporciona un número
de func iones que devuelven las rutas a los diferentes archivos de configurac ión y directorios. Es to
invalida la nec es idad de que las aplicac iones codifiquen a fuego las rutas espec ialmente debido a que
la ubicac ión de la política activa depende de la configurac ión SELINUXTYPE en /etc/selinux/
config.
Por ejemplo, si SELINUXTYPE es configurado como strict la ubicac ión de la política activa se
enc uentra bajo /etc/selinux/strict.
Para dver la lista de las funciones disponibles utilice el siguiente c omando:
man 3 selinux_binary_polic y_pa th
751
El Papel de la Política durante el Proc eso de Arranque
Nota
Esta página del manuel se enc uentra disponible sólamente si tiene el RPM
libselinux-devel instalado.
El uso de libselinux y las func iones relac ionadas se enc uentra fuera del alc anc e
de este doc umento.
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 s is tema. Debido a
que los proc esos deben ser etiquetados con su dominio correcto, init realiza algunas operac iones
esenc iales de manera temprana durante el proc eso de arranque para mantener la sincronizac ión
entre el etiquetado y el refuerzo de polític as.
1. Después de que se ha cargado el kernel durante el proc eso de arranque, se le as igna al proc eso
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ític a.
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 enc uentra ac tivado en el kernel.
3. Si init no enc uentra SELinux en el kernel o si se enc uentra desactivado por medio del
parámetro boot selinux=0 o si /etc/selinux/config espec if ic a que SELI NUX=disable d
entonc es el proc eso de arranque proc ede 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 proc ess, such as
enforcing=0 or enforcing=1. The kernel does not enforc e any policy until the initial policy is
loaded.
4. Si SELinux se encuentra presente, se monta /selinux/.
5. init c hec ks /selinux/policyvers for the supported policy version. The version number in
/selinux/policyvers is the latest policy version your kernel supports. init inspec ts /etc/
selinux/config to determine which policy is active, such as the targeted policy, and loads the
assoc iated file at $SELINUX_PO LICY/policy. <version>.
Si la política binaria no es la versión soportada por el kernel entonc es init intenta cargar el
archivo de políticas si es una versión anterior. Esto proporc ina una compatibilidad retroactiva con
vers iones de políticas previas.
Si la configurac ión local en /etc/selinux/targeted/booleans es diferente de la compilada
en la política entonc es init modifica la política en la memoria con base en la configurac ión local
antes de cargar la política en el kernel.
6. En este punto del proc eso, la política se enc uentra c ompletamente c argada 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 rec uperar c ontextos de seguridad dinámic amente desde el servidor de seguridad que
se encuentra en el kernel.
752
El Papel de la Política durante el Proc eso de Arranque
7. Después init se re-ejec uta a sí mismo para que pueda regresar a un dominio diferente si al
política lo define. Para la política objetivo no hay una trans ic ión definida y init permanec e en el
dominio unconfined_t.
8. En este punto, init continua con su proc eso normal de arranque.
The reason that init re-exec utes 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 proc ess can enter a domain is during exec ution, which means that such processes are the only entry
points into the domains.
Por ejemplo, si la política ha espec if ic ado 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 ejec uc ión correcto
para init. Debido a que puede nec es itarse que ocurra esta trans ic ión, init es codificado para re-
ejec utarse 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 trans ition
occurs on anything exec uting in the kernel_t domain that exec utes a file of type init_exec _t. When
this execution occ urs, the new proc ess is ass igned 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 hac iendo más fácil agrupar ciertos permisos de
ac uerdo con clases espec if ic as. Por ejemplo:
• Clases relac ionadas con archivos incluyen filesystem para sistemas de archivos, file para
archivos y dir para directorios. Cada c lase tiene su propio grupo de permisos asoc iados.
La c lase filesystem puede montar, desmontar, obtener atr ibutos, establec er cuotas, re-etiquetar,
etc. La clase file tiene permisos de arc hivos c omúnes lectura, escritura, obtener y configurar
atr ibutos, bloquear, re-etiquetar, enlazar, renombrar, añadir, etc.
• Las clases realc ionadas con la red incluyen tcp_socket para soc kets TCP, netif para interfac es
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 dec larac iones que coinc iden 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ámic amente c lases y
permisos.
Los permisos son acc iones que un sujeto puede realizar en un objeto si la política lo permite. Es tos
permisos son las petic iones de acceso que SELinux permite o rechaza ac tivamente.
44.8. Sinopsis de la Política de Objetivos Este capítulo es una sinops is 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 ubicac ión de arc hivos y el tipo de c ontenido en esos archivos. La diferenc ia 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 restr icted 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
ejec utan en los dominios httpd_t y ntpd_t, respectivamente. Sin embargo, el demonio ssh no está
protegido en esta política y por consec uenc ia ejec uta en el dominio unconfined_t.
Refiérase a la siguiente salida de ejemplo, la cual ilustra los diversos dominios para los demonios
menc ionados anteriormente:
user_u:syste m_r:httpd_t 25 1 29 ?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 oppos ite 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 trans itions are individually cons idered
within the policy rules.
La política estr icta es un entorno mucho más complejo y no se envía junto con Red Hat Enterprise
Linux. Este manual se encfoc a 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 instalac ió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. Us ua rios y Roles en la Política Objetivo
Esta sección cubre los rroles específ ic os activados para la política objetivo.
754
¿Qué es la Política Objetivo?
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 betw een 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 dec larac iones en la política, no hay un solo archivo que dec lare todos los roles
(rec uerde que la política misma es generada de un número de archivos separados).
system_r
El rol es para todos los proc esos del s istema a exc epc ión de los proc esos 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_scr ipt_t
initrc_t
ldc onfig_t
mailman_cgi_t
mailman_mail_t
mailman_queue_t
mysqld_t
n am ed_ t
ndc_t
nscd_t
ntpd_t
pegasus_t
portmap_t
postgresql_t
sn m p d_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
estr ic ta, los usuar ios individuales pueden llegar a utilizarse, permitiendo a los usuarios tener roles
espec iales para realizar operac iones privilegiadas. En la política de objetivos todos los usuarios
ejec utan en el dominio unconfined_t.
object_r
En SELinux, los roles no se utilizan para objetos cuando RBAC se está utilizando. LOs roles son
estr ictamente para sujetos. Esto se debe a que los roles son orientados a tareas y agrupan
entidades las cuales relaizan acc iones (por ejemplo, proc esos). 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 sustituc ión en la etiqueta.
Any role could have been cho sen for the targeted policy, but system_r alr eady had existing authorization for the daemon
do main s, simplifying the process. This was done because no mechan ism currently exists to alias roles.
755
¿Qué es la Política Objetivo?
sysadm_r
Este es el rol del administrador del s istema en una política estr ic ta. Si inicia la ses ión
directamente como usuario root el rol predeterminado puede ser de hec ho staff_r. Si
es verdadero utilice el comando newrole -r sysadm_r para cambiar al rol del
administrador del s istema de SELinux para realizar tareas de administrac ión del s istema.
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 s ingle user in the targeted policy makes it eas ier to c hange 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 res tarts a daemon originally started by init.
A user aliasing mechan ism wo uld also work here, to alias all identities from the strict policy to a single user
identity in the target ed policy.