Permisos SELinux

Antes de comprender SELinux, primero comprendamos las dos estrategias de control de acceso de Linux: DAC y MAC

DAC, control de acceso total. El sistema solo proporciona autenticación básica, el desarrollador controla el control de acceso completo.

DAC divide a los visitantes del recurso en tres categorías: propietario, grupo y otros.

?Los permisos de acceso también se dividen en tres tipos: lectura, escritura y ejecución

Los recursos establecen diferentes permisos de acceso para los visitantes de los recursos.

Bajo el mecanismo DAC, el proceso de cada usuario tiene todos los permisos del usuario de forma predeterminada.

Hay dos problemas graves con DAC:

?Problema 1:

?Dado que el usuario Root tiene todos los permisos, las restricciones de DAC para los usuarios Root no funcionan . A partir del kernel de Linux 2.1, Linux divide los permisos de raíz en múltiples capacidades de raíz según diferentes escenarios de aplicación, y los usuarios comunes también pueden configurarse con una determinada capacidad de raíz. Los usuarios habituales también pueden evitar las restricciones de DAC si tienen configurado CAP_DAC_OVERRIDE.

?Problema 2:

?El proceso de usuario tiene todos los permisos del usuario y puede modificar/eliminar todos los recursos de archivos del usuario, lo que dificulta la prevención del malware.

Como puede ver, DAC tiene fallas obvias. Una vez comprometido, un proceso de usuario con privilegios de root puede hacer lo que quiera. Las primeras versiones de Android se vieron afectadas por esto.

MAC, Control de Acceso Obligatorio. El sistema impone límites estrictos a cada acceso, con límites específicos dados por el desarrollador.

Linux MAC soluciona las deficiencias de DAC al exigir que el sistema valide cada acceso, cada acceso a un recurso de archivo, según una política definida. El sistema puede controlar permisos para procesos específicos y recursos de archivos específicos. Incluso el usuario root, que pertenece a un proceso diferente, no necesariamente obtiene privilegios de root, sino que depende de las restricciones de acceso predefinidas de la política del proceso. Si no puede pasar la autenticación MAC, no hay nada que pueda hacer.

A diferencia de DAC, el "sujeto" del control de acceso MAC es el "proceso" y no el usuario. Esto limita el abuso de los privilegios de root y requiere un desglose más completo de cada privilegio para limitar el acceso de los usuarios a los recursos.

SELinux es actualmente el mejor mecanismo MAC y el estándar de la industria.

SELinux (Security Enhanced Linux) es un mecanismo de Control de Acceso Obligatorio (MAC) desarrollado por la Agencia de Seguridad Nacional (NSA) con la participación de varias organizaciones sin fines de lucro y universidades. SELinux se lanzó por primera vez en diciembre de 2000 bajo la licencia GPL. Actualmente, SELinux está integrado en el kernel de Linux 2.6 y superior.

SELinux se divide en tres modos:

Android 5.x y superiores obligan a SELinux a estar habilitado, por lo que el modo deshabilitado ya no es útil. Por lo general, al depurar, habilitaremos el modo Permissve para encontrar tantos problemas como sea posible y resolverlos todos a la vez. Durante la producción, el modo Enfocing está habilitado para proteger el sistema.

Ver el modo SELinux: adb shell getenforce

Establecer el modo SELinux: adb shell setenforce 1 //0 es Permisivo, 1 es Enfocing

Diagrama de control de acceso de SELinux:

Generalmente nuestro proceso de desarrollo consiste en configurar sujetos, objetos y políticas de seguridad.

SELinux asigna un contexto de seguridad a todos los objetos en Linux, que se describe como una cadena estándar.

El formato estándar del contexto de seguridad: usuario:rol:tipo[:alcance]

Las etiquetas de seguridad se utilizan para vincular los recursos a los que se accede a los contextos de seguridad y describir la correspondencia entre ellos. El formato estándar es: res recurso contexto_seguridad, es decir: res usuario:rol:tipo[:rango]. Además de expresiones regulares como * y ?, aquí también se pueden usar comodines, como net para vincular todas las propiedades que comienzan con net. Las etiquetas de seguridad se definen en contextos_tipo, por ejemplo, el archivo se define en contextos_archivo, el servicio se define en contextos_servicio y la propiedad se define en contextos_propiedad.

Ejemplo:

file_contexts:

service_contexts:

Para ver el contexto de seguridad del proceso: ps -AZ . Por ejemplo, para ver el contexto de seguridad del proceso de "configuración", use ps -AZ | grep settings:

?u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android. settings

Para ver el contexto de seguridad de un archivo: ls -Z . Por ejemplo, para ver el contexto de seguridad del archivo build.prop:

?u:object_r:system_file: s0 build.prop

La aplicación de tipos (TE) es el proceso de revisión de permisos basados ​​en tipos en el contexto de seguridad. El tipo de sujeto proporciona ciertos permisos sobre si un determinado tipo en el tipo de objeto tiene derechos de acceso. Actualmente es el mecanismo de revisión MAC más utilizado, que es simple y fácil de usar.

Formato de la declaración de control TE: nombre_regla tipo_fuente tipo_destino: clase conjunto_perm

Descripción de las reglas de ejecución de tipos:

Tomando logd.te como ejemplo, se definen reglas TE en tombstoned.te en:

?allow logd runtime_event_log_tags_file:file rw_file_perms;

?dontaudit domain runtime_event_log_tags file }:dir_file_class_set write

Cada proceso o archivo en SELinux Hay un tipo y cada tipo tiene una o más propiedades. Todos los atributos comunes se definen en los siguientes archivos:

?system/sepolicy/public/attributes

?system/sepolicy/prebuilts/api/[build version]/public/attributes

?system/sepolicy/prebuilts/api/[versión de compilación]/public/attributes

?api/[versión de compilación]/privado/atributos

donde [ versión de compilación] es el número de versión de Android, por ejemplo, Android O es 28.0. Definiciones de atributos comunes:

Un tipo corresponde a uno o más atributos. Formato de definición de atributos y tipos:

?type type_name, atributo1, atributo2

Las definiciones de tipos suelen estar dispersas en cada archivo.

Por ejemplo, el tipo de archivo ordinario se define en file.te:

SEAndroid define diferentes clases para diferentes tipos de recursos, como archivos ordinarios, sockets, etc., como la seguridad utilizada por SELinux, como como parámetros de proceso, etc. Cada clase tiene sus propios permisos. Por ejemplo, los archivos tienen permisos de lectura, escritura, creación, getattr, setattr, lock, ioctl y otros. Por ejemplo, el proceso tiene permisos fork, sigchld, sigkill, ptrace, getpgid, setpgid y otros. Estas clases y sus permisos se definen en los siguientes archivos:

?system/sepolicy/private/access_vectors

?system/sepolicy/reqd_mask/access_vectors

? system /sepolicy/reqd_mask/access_vectors

?system/sepolicy/reqd_mask/access_vectors

03-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: escriba = 1400 auditoría (0.0:481): avc: denegado {lectura} para nombre="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device : s0 tclass=chr_file permissive=0

Solución:

Modificar platform_app. te, agrega:

?allow platform_app als_ps_device:chr_file r_file_perms;

(1). Las reglas de Neverallow no se cumplen ni se modifican

Error de compilación:

?neverallow check falló en xxx

El elemento de prueba CTS falló:

?android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX

Aprovisionamiento de Android O esto Es especialmente probable que este tipo de problema ocurra después de que se separan el proveedor y el sistema. Básicamente, estos problemas se deben a la modificación o adición de configuraciones que no cumplen con las reglas de nunca permitir, lo que genera errores de compilación. Para solucionar el error de compilación, se cambiaron las reglas de neverallow. Finalmente, al ejecutar CTS, los proyectos de prueba relevantes fallaron.

Solución:

(2). El proceso init no realizó el cambio de dominio al bifurcar un nuevo proceso.

El proyecto de prueba CTS falló:

?android.security.cts.SELinuxDomainTest # testInitDomain

Idea:

Bifurcar el proceso. Al realizar un cambio de dominio, consulte la Sección 3.4.

Este artículo se refiere principalmente al contenido del inicio rápido de MTK-Online "Análisis rápido de problemas de SELinux" y agradece al autor original por su arduo trabajo. Además, también agregué algunos de mis propios conocimientos y prácticas basados ​​en el código fuente y mis propias prácticas de desarrollo.