Conceptos de SELinux

Revisa esta página para familiarizarte con los conceptos de SELinux.

Control de acceso obligatorio

Security Enhanced Linux (SELinux) es un sistema de control de acceso obligatorio (MAC) para el sistema operativo Linux. Como sistema MAC, difiere de la arquitectura conocido como el sistema de control de acceso discrecional (DAC). En un sistema DAC, un concepto de propiedad, en la que el propietario de un recurso concreto controla el acceso permisos asociados. Por lo general, esto es general a la elevación de privilegios no deseada. En cambio, un sistema MAC consulta a una entidad autoridad para tomar una decisión sobre todos los intentos de acceso.

SELinux se implementó como parte del módulo de seguridad de Linux (LSM). que reconoce varios objetos de kernel y acciones sensibles realizar en ellos. En el momento en que cada una de estas acciones se llevaría a cabo se llama a una función hook LSM para determinar si acción debería permitirse en función de la información almacenada en un lugar objeto de seguridad en la nube. SELinux proporciona una implementación para estos hooks y de estos objetos de seguridad, que se combina con su propia política, para determinar las decisiones de acceso.

Junto con otras medidas de seguridad, el control de acceso de Android política limita en gran medida el daño potencial de las máquinas comprometidas y cuentas de servicio. Usar herramientas como el acceso discrecional y obligatorio de Android te brinda una estructura para garantizar que tu software se ejecute solo en de privilegios mínimos. Esto mitiga los efectos de los ataques y reduce la la probabilidad de que procesos erróneos reemplacen o, incluso, transmitan datos.

En Android 4.3 y versiones posteriores, SELinux proporciona un control de acceso obligatorio (MAC). que abarca los entornos tradicionales de control de acceso discrecional (DAC). Para por lo general, el software debe ejecutarse como la cuenta de usuario raíz para escribir de almacenamiento en bloque. En un entorno de Linux tradicional basado en DAC, si el usuario raíz se ve comprometido que el usuario pueda escribir en cada dispositivo de bloque sin procesar. Sin embargo, Se puede usar SELinux para etiquetar estos dispositivos, de modo que el proceso le asigne la raíz puede escribir solo a los especificados en la política asociada. En este el proceso no puede sobrescribir los datos y la configuración del sistema fuera del dispositivo de bloque sin procesar específico.

Consulta Casos de uso para ver más ejemplos de amenazas y formas de abordarlas con SELinux.

Niveles de aplicación

SELinux puede implementarse de diferentes modos:

  • Permisiva: La política de seguridad de SELinux no se aplica, solo se registra.
  • Aplicación: La política de seguridad se aplica de manera forzosa y se registra. Errores aparecerán como errores EPERM.

Esta opción es binaria y determina si tu política toma medidas o te permite reunir posibles fallas. Permisivo es especialmente útil durante para implementarlos.

Tipos, atributos y reglas

Android se basa en el componente de aplicación de tipos (TE) de SELinux para su . Significa que todos los objetos (como archivo, proceso o socket) tienen un type asociados. Por ejemplo, de forma predeterminada, una app tendrá el tipo untrusted_app. Para un proceso, su tipo también es conocido como dominio. Es posible anotar un tipo con uno o varios atributos. Los atributos son útiles para hacer referencia a varios tipos al mismo tiempo.

Los objetos se asignan a clases. (p.ej., un archivo, un directorio, un vínculo simbólico, un socket) y los diferentes tipos de acceso de cada clase están representados por permisos. Por ejemplo, el permiso open existe para la clase file Si bien los tipos y atributos se actualizan regularmente como parte la política de SELinux de Android, los permisos y las clases se definen de forma estática y rara vez se actualiza como parte de una nueva versión de Linux.

Una regla de política tiene el siguiente formato: allow source target:class permissions; En el ejemplo anterior, se ilustra lo siguiente:

  • Fuente: Tipo (o atributo) del sujeto de la regla. ¿Quién solicita el acceso?
  • Destino: El tipo (o atributo) del objeto. ¿A qué datos se solicita el acceso?
  • Clase: El tipo de objeto (p.ej., archivo, socket) al que se accede.
  • Permisos: Indica la operación (o el conjunto de operaciones) (p.ej., lectura o escritura) que se realiza.

El siguiente es un ejemplo de una regla:

allow untrusted_app app_data_file:file { read write };

Esto indica que las apps pueden leer y escribir archivos etiquetados como app_data_file Existen otros tipos de aplicaciones. Para instancias, isolated_app se usa para servicios de apps con isolatedProcess=true en su manifiesto. En lugar de repetir para ambos tipos, Android usa un atributo llamado appdomain para todos los tipos que abarcan aplicaciones:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

Cuando se escribe una regla que especifica un nombre de atributo, ese nombre se automáticamente a la lista de dominios o tipos asociados con el . Estos son algunos atributos notables:

  • domain: Es un atributo asociado con todos los tipos de procesos.
  • file_type: Es un atributo asociado con todos los tipos de archivo.

Macros

Para el acceso a archivos en particular, existen muchos tipos de permisos para tener en cuenta. Por ejemplo, el permiso read no es suficiente para abrir el archivo o llama a stat en él. Para simplificar la definición de la regla, Android proporciona un conjunto de macros para manejar los casos más comunes. Por ejemplo, para incluir los permisos faltantes, como open, la regla anterior podría reescribirse de la siguiente manera:

allow appdomain app_data_file:file rw_file_perms;

Consulta la global_macros y te_macros para ver más ejemplos de macros útiles. Las macros se deben usar siempre que sea posible para ayudar a reducir la probabilidad de fallas debidas a denegaciones relacionadas con permisos.

Una vez que se define un tipo, se debe asociar con el archivo o proceso representa. Consulta Implementación de SELinux. para obtener más información sobre cómo se realiza esta asociación. Para obtener más información consulta la Notebook de SELinux.

Contexto y categorías de seguridad

Cuando depures políticas de SELinux o etiquetes archivos (mediante file_contexts o cuando estés en ls -Z), puedes en un contexto de seguridad (también conocido como etiqueta). Para ejemplo: u:r:untrusted_app:s0:c15,c256,c513,c768 Un contexto de seguridad tiene el siguiente formato: user:role:type:sensitivity[:categories] Por lo general, puedes ignorar Campos user, role y sensitivity de un (consulta Especificidad). El type se explica en la sección anterior. categories son parte de la Seguridad de varios niveles (MLS) y la compatibilidad con SELinux. Desde Android S, las categorías se usan para lo siguiente:

  • Aislar los datos de app del acceso de otra app
  • Aísla los datos de app de un usuario físico de otro.

Especificidad

Android no usa todas las funciones que proporciona SELinux. Durante la lectura documentación externa, ten en cuenta estos puntos:

  • La mayoría de las políticas del AOSP se definen con el lenguaje de políticas de kernel. Existen algunas excepciones para el uso del lenguaje intermedio común (CIL).
  • No se usan los usuarios de SELinux. El único usuario definido es u Cuando es necesario, los usuarios físicos se representan a través del campo de categorías de un contexto de seguridad.
  • No se usan los roles de SELinux ni el control de acceso basado en roles (RBAC). Se definen y usan dos roles predeterminados: r para sujetos y object_r para objetos.
  • No se usan las sensibilidades de SELinux. La sensibilidad de s0 predeterminada siempre está configurada.
  • No se usan booleanos SELinux. Una vez que se crea la política para un dispositivo, no depende del estado del dispositivo. Esto simplifica el la auditoría y depuración de políticas.