Your SlideShare is downloading. ×
44  seguridad y se linux
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

44 seguridad y se linux

1,171
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,171
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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.
  • 2. 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:
  • 3. 733 Archivos relacionados con SELinux 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
  • 4. 734 Archivos relacionados 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 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.
  • 5. 735 Archivos relacionados con SELinux 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
  • 6. 736 Archivos relacionados con SELinux 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.
  • 7. 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.
  • 8. 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.
  • 9. 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.
  • 10. 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
  • 11. 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
  • 12. 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:
  • 13. 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
  • 14. 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 [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 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 [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 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.
  • 15. 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:
  • 16. 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".
  • 17. 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.
  • 18. 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
  • 19. 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.
  • 20. 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
  • 21. 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.
  • 22. 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.
  • 23. 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.
  • 24. 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 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.
  • 25. 755 ¿Qué es la Política Objetivo? 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.