Personaliza SELinux

Después de integrar el nivel básico de funcionalidad de SELinux y un análisis exhaustivo de los resultados, puede agregar su propia configuración de política para abarcar tus personalizaciones para el sistema operativo Android. Estas políticas deben cumplir con el Programa de compatibilidad de Android y no debe quitar la configuración de SELinux predeterminada.

Los fabricantes no deben quitar la política de SELinux existente. De lo contrario, pueden corren el riesgo de romper la implementación de SELinux de Android y las aplicaciones que que administra. Esto incluye aplicaciones de terceros que probablemente se deban para garantizar el cumplimiento y ser operativa. Las aplicaciones no deben requerir para seguir funcionando en dispositivos habilitados para SELinux.

Cuando comiences a personalizar SELinux, recuerda lo siguiente:

• Escribir política de SELinux para todos los daemons nuevos
• Usa dominios predefinidos cuando sea apropiado
• Asigna un dominio a cualquier proceso generado como un servicio init.
• Familiarízate con las macros antes de escribir la política
• Cómo enviar cambios de la política principal al AOSP

Y recuerda no hacer lo siguiente:

• Crear una política incompatible
• Permitir la personalización de la política del usuario final
• Permitir la personalización de la política de MDM
• Asustar a los usuarios con incumplimientos de política
• Agregar puertas traseras

Consulta la sección Funciones de seguridad del kernel de la En Android Documento de Definición de compatibilidad para requisitos específicos.

SELinux utiliza un enfoque de lista de entidades permitidas, lo que significa que todo acceso debe ser explícitamente permitidos en la política para que se otorguen. Como el SELinux predeterminado ya es compatible con el Proyecto de código abierto de Android, no es obligatorio modificar la configuración de SELinux de ninguna manera. Si personalizas la configuración de SELinux, tenga mucho cuidado de no dañar las aplicaciones existentes. Para comenzar, sigue estos pasos:

1. Usa el la versión más reciente de Android kernel.
2. Adopta el principio de privilegio mínimo.
3. Ingresa solo las que se agreguen a Android. La política predeterminada funciona con la página de inicio de código Project automáticamente.
4. Compartimentan los componentes de software en módulos que realizan tareas.
5. Crear políticas de SELinux que aíslen esas tareas de las tareas no relacionadas funciones.
6. Coloca esas políticas en archivos *.te (la extensión para SELinux) archivos de origen de la política) en la /device/manufacturer/device-name/sepolicy y usa las variables BOARD_SEPOLICY para incluirlos en tu compilación.
7. Haz que los nuevos dominios sean permisivos al principio. Esto se hace usando una estructura permisiva en el archivo .te del dominio.
8. Analiza los resultados y define mejor las definiciones de tu dominio.
9. Quita la declaración de permisivo cuando no aparezcan más denegaciones en userdebug compilaciones.

Una vez que hayas integrado el cambio de política de SELinux, agrega un paso al para garantizar la compatibilidad con SELinux en el futuro. En una situación ideal desarrollo de software, la política de SELinux cambia solo cuando los cambios del modelo, no la implementación real.

Cuando empieces a personalizar SELinux, primero audita las adiciones que hayas agregado a Android. Si agregaste un componente que realiza una nueva función, asegúrate de que el componente cumpla con la política de seguridad de Android, así como con cualquier política asociada creada por con el OEM, antes de activar el modo de aplicación forzosa.

Para evitar problemas innecesarios, es mejor ser demasiado amplio demasiado restrictivo e incompatible, lo que da como resultado funciones del dispositivo. Por el contrario, si tus cambios beneficiarán a otros, deberías envía las modificaciones a la política SELinux predeterminada como parche. Si el parche es se aplicó a la política de seguridad predeterminada, no tendrás que hacer este cambio con con cada versión nueva de Android.

Ejemplos de declaraciones de políticas

SELinux se basa en el M4 lenguaje informático y, por lo tanto, admite una variedad de macros para ahorrar tiempo.

En el siguiente ejemplo, a todos los dominios se les otorga acceso de lectura o escribir en /dev/null y leer desde /dev/zero

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Esta misma sentencia puede escribirse con *_file_perms de SELinux. macros (abreviatura):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Ejemplo de política

A continuación, se muestra un ejemplo completo de la política para DHCP, que examinamos a continuación:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Analicemos el ejemplo en detalle:

En la primera línea, la declaración de tipo, el daemon DHCP hereda del política de seguridad básica (domain). De la declaración anterior ejemplos, DHCP puede leer y escribir en /dev/null.

En la segunda línea, DHCP se identifica como un dominio permisivo.

En la línea init_daemon_domain(dhcp), la política indica que DHCP es generado a partir de init y puede comunicarse con él.

En la línea net_domain(dhcp), la política permite que DHCP use funcionalidades de red comunes del dominio net, como la lectura escribir paquetes de TCP, comunicarse a través de sockets y conducir solicitudes.

En la línea allow dhcp proc_net:file write;, la política indica DHCP puede escribir en archivos específicos de /proc. Esta línea demuestra Etiquetado detallado de archivos de SELinux. Usa la etiqueta proc_net para limitar el acceso de escritura solo a los archivos en /proc/sys/net.

El último bloque del ejemplo que comienza con allow dhcp netd:fd use; describe cómo se permite a las aplicaciones interactúan entre sí. La política indica que DHCP y netd pueden comunicarse con a través de descriptores de archivos, archivos FIFO, sockets de datagramas y transmisión de UNIX enchufes. DHCP solo puede leer y escribir desde los sockets del datagrama y UNIX sockets de transmisión y no crearlos ni abrirlos.

Controles disponibles

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

reglas nunca permitir

Las reglas neverallow de SELinux prohíben comportamientos que nunca deberían ocurrir. Con las pruebas de compatibilidad, Las reglas neverallow de SELinux ahora se aplican en todos los dispositivos.

Los siguientes lineamientos están destinados a ayudar a los fabricantes a evitar errores relacionadas con las reglas neverallow durante la personalización. Los números de la regla que se usan aquí corresponden a Android 5.1 y están sujetas a cambios según su versión.

Regla 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Consulta la página del manual de ptrace. El sys_ptrace otorga la capacidad de ptrace cualquier proceso, lo que permite una gran cantidad de control sobre otros procesos y debe pertenecer solo al sistema designado que se describen en la regla. La necesidad de esta capacidad a menudo indica la presencia de algo que no está destinado a compilaciones para el usuario o que no son necesarias. Quita el componente innecesario.

Regla 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Esta regla está diseñada para evitar la ejecución de código arbitrario en el sistema. Específicamente, declara que solo se ejecuta el código en /system. lo que ofrece garantías de seguridad gracias a mecanismos como el inicio verificado. A menudo, la mejor solución cuando se encuentra un problema con esto La regla neverallow consiste en mover el código ofensivo al /system.

Cómo personalizar SEPolicy en Android 8.0 y versiones posteriores

En esta sección, se proporcionan pautas para la política SELinux del proveedor en Android 8.0 y más recientes, incluidos detalles sobre SEPolicy del Proyecto de código abierto de Android (AOSP) y SEPolicy de extensiones. Para obtener más información sobre cómo se mantiene la política entre particiones y versiones de Android, consulta Compatibilidad.

Posición de la política

En Android 7.0 y versiones anteriores, los fabricantes de dispositivos podían agregar políticas a BOARD_SEPOLICY_DIRS, incluida la política destinada a aumentar la política del AOSP en diferentes tipos de dispositivos. En Android 8.0 y versiones posteriores, agregar una política a BOARD_SEPOLICY_DIRS coloca la política solo en el proveedor. imagen.

En Android 8.0 y versiones posteriores, la política existe en las siguientes ubicaciones del AOSP:

• system/sepolicy/public. Incluye la política exportada para su uso en la política específica del proveedor. Todo se incluye en Android 8.0 infraestructura de compatibilidad. La política pública debe persistir en todas las versiones para que puedas incluir cualquier /public en tu política personalizada. Por este motivo, el tipo de política que se puede colocar en /public es más restringido. Piensa, por ejemplo, en la API de políticas exportadas de la plataforma: se encarga de la interfaz entre /system y /vendor pertenece a esta ubicación.
• system/sepolicy/private. Incluye la política necesaria para el funcionamiento de la imagen del sistema, pero de qué política de imágenes del proveedor no tienen conocimientos.
• system/sepolicy/vendor; Incluye la política para los componentes que van en /vendor, pero existen en el árbol de la plataforma principal (no directorios específicos del dispositivo). Este es un artefacto del sistema distinción entre dispositivos y componentes globales conceptualmente, se trata de un parte de la política específica del dispositivo que se describe a continuación.
• device/manufacturer/device-name/sepolicy. Incluye la política específica del dispositivo. También incluye las personalizaciones de los dispositivos que, en Android 8.0 y versiones posteriores, corresponde a la política para componentes en la imagen del proveedor.

En Android 11 y versiones posteriores, las particiones system_ext y product también pueden incluir políticas específicas de cada partición. system_ext y las políticas de productos también se dividen en pública y privada, y los proveedores pueden usar la política políticas, como la del sistema.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS Incluye la política exportada para usar en la política específica del proveedor. Se instaló en la partición system_ext.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS Incluye la política necesaria para el funcionamiento de la imagen system_ext, pero ¿de qué imagen del proveedor no debería tener conocimientos. Se instaló en la partición system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS Incluye la política exportada para usar en la política específica del proveedor. Se instaló en la partición del producto.
• PRODUCT_PRIVATE_SEPOLICY_DIRS Incluye la política necesaria para el funcionamiento de la imagen del producto, pero de qué política de imágenes del proveedor no debería tener conocimientos. Se instaló en la partición del producto.

Situaciones de políticas admitidas

En los dispositivos que se lanzan con Android 8.0 y versiones posteriores, la imagen del proveedor debe funcionar con la imagen del sistema OEM y la imagen del sistema del AOSP de referencia proporcionada por Google (y pasa el CTS en esta imagen de referencia). Estos requisitos garantizan un y la separación entre el framework y el código del proveedor. Estos dispositivos admiten la las siguientes situaciones.

Extensiones solo de imagen para proveedores

Ejemplo: Agrega un servicio nuevo a vndservicemanager de la imagen del proveedor que admite procesos a partir de la imagen del proveedor.

Al igual que con los dispositivos que se lanzan con versiones anteriores de Android, agrega funciones específicas para el dispositivo la personalización en device/manufacturer/device-name/sepolicy Nueva política que regula cómo interactúan los componentes del proveedor (únicamente) con otro proveedor componentes deben incluir tipos presentes solo en device/manufacturer/device-name/sepolicy La política escrita aquí permite que funcione el código del proveedor; no se actualizará como parte. de una OTA solo de framework y estará presente en la política combinada en un dispositivo con la imagen del sistema del AOSP de referencia.

asistencia para las imágenes del proveedor con AOSP

Ejemplo: Agregar un nuevo proceso (registrado con hwservicemanager de la imagen del proveedor) que implementa un HAL definida por AOSP.

Al igual que con los dispositivos que se lanzan con versiones anteriores de Android, realiza la personalización específica del dispositivo en device/manufacturer/device-name/sepolicy La política que se exportó como parte de system/sepolicy/public/ está disponible para su uso y se envía como parte de la política del proveedor. Tipos y atributos de la política pública se puede usar en nuevas reglas que dicten interacciones con el nuevo bits específicos del proveedor, sujetos a la neverallow proporcionada de manera predeterminada. Al igual que con el caso exclusivo del proveedor, aquí la nueva política no se actualizará. como parte de una OTA solo de framework y estará presente en la política combinada en una dispositivo con la imagen del sistema del AOSP de referencia.

extensiones solo de imagen del sistema

Ejemplo: Agregar un servicio nuevo (registrado con servicemanager) al que solo acceden otros procesos desde la imagen del sistema.

Agrega esta política a system/sepolicy/private. Puedes agregar objetos o procesos para habilitar la funcionalidad en una imagen del sistema del socio, siempre esos nuevos bits no necesitan interactuar con nuevos componentes en la imagen del proveedor (específicamente, estos objetos o procesos deben funcionar completamente sin políticas de la imagen del proveedor). La política que exporta system/sepolicy/public tiene las siguientes características: disponible aquí, al igual que para las extensiones solo de imagen del proveedor. Esta política es parte de la imagen del sistema y podrían actualizarse de forma inalámbrica solo de framework, pero no debe estar presente cuando se usa la imagen del sistema del AOSP de referencia.

imagen-del-proveedor extensiones que entregan componentes extendidos del AOSP

Ejemplo: Una nueva HAL que no pertenece al AOSP para uso de clientes ampliados que también puede haber en la imagen del sistema del AOSP (por ejemplo, en un system_server extendido).

La política de interacción entre el sistema y el proveedor debe incluirse en el device/manufacturer/device-name/sepolicy que se envía en la partición del proveedor. Esto es similar a la situación anterior de agregar compatibilidad con imágenes del proveedor al trabajo. con la imagen del AOSP de referencia, salvo que los componentes del AOSP modificados también puedan requieren políticas adicionales para funcionar correctamente con el resto del sistema partición (lo cual está bien siempre y cuando todavía tengan el tipo público de AOSP etiquetas).

Política para la interacción de componentes públicos del AOSP con la imagen del sistema Las extensiones deben estar en system/sepolicy/private.

imagen-del-sistema extensiones que solo acceden a interfaces del AOSP

Ejemplo: Un nuevo proceso del sistema ajeno al AOSP debe acceder a la HAL en en la que se basa el AOSP.

Esto es similar a system-image-only de extensión, con la excepción de que los nuevos componentes del sistema pueden interactuar en la system/vendor. La política del nuevo componente del sistema ir en system/sepolicy/private, lo cual es aceptable siempre que sea a través de una interfaz ya establecida por el AOSP en system/sepolicy/public (es decir, los tipos y atributos necesarios para funciones disponibles). Si bien la política podría estar incluida en la columna política, no podrá usar otros system/sepolicy/private o cambios (de cualquier manera que afecte a las políticas) como resultado de un enfoque actualización. Es posible que la política se cambie de manera inalámbrica solo por el framework, pero no se modificará presente cuando se usa una imagen del sistema del AOSP (que no tendrá el diseño ninguna de las dos).

imagen-del-proveedor extensiones que entregan componentes del sistema nuevos

Ejemplo: Agregar una nueva HAL que no es de AOSP para que la use un proceso de cliente sin un análogo de AOSP (y, por lo tanto, requiere su propio dominio).

Al igual que las extensiones del AOSP ejemplo, la política de interacciones entre el sistema y el proveedor debe incluirse en device/manufacturer/device-name/sepolicy directorio enviado en la partición del proveedor (para garantizar que la política del sistema no tenga conocimiento de los detalles específicos del proveedor) Tú puedes agregar nuevos tipos públicos que extiendan la política system/sepolicy/public; esto solo debe hacerse además del política del AOSP existente, es decir, no quites la política pública del AOSP. El nuevo público se pueden usar para políticas en system/sepolicy/private y en device/manufacturer/device-name/sepolicy

Ten en cuenta que cada adición a system/sepolicy/public agrega la complejidad exponiendo una nueva garantía de compatibilidad a la que se deba hacer un seguimiento de asignación y que está sujeta a otras restricciones. Solo los tipos nuevos Es posible que se agreguen las reglas de permiso correspondientes en system/sepolicy/public. no se admiten atributos ni otras declaraciones de políticas. Además, los nuevos los tipos públicos no se pueden usar para etiquetar directamente objetos en el Política /vendor.

Casos de incumplimiento de políticas no admitidos

Los dispositivos que se lanzan con Android 8.0 y versiones posteriores no admiten lo siguiente: situación de política y ejemplos.

Adicional extensiones de imagen del sistema que necesiten permiso a nuevos componentes de imagen del proveedor después de una OTA solo para frameworks

Ejemplo: Un nuevo proceso del sistema ajeno al AOSP, que requiere sus propios dominio, se agregará en la próxima versión de Android y necesita acceder a un nuevo dominio HAL que no son del AOSP.

Similar a nuevo Interacción de componentes del sistema y el proveedor (que no son del AOSP), excepto en el nuevo sistema se ingresa el tipo OTA solo para el framework. Si bien el nuevo tipo se podría agregar a la política en system/sepolicy/public, la política del proveedor existente no tiene conocimientos del nuevo tipo, ya que solo realiza un seguimiento de la política pública del sistema Android 8.0. Para controlar esto, el AOSP expone los recursos proporcionados por el proveedor a través de un atributo (p.ej., hal_foo), pero, como atributo, las extensiones de socio no están compatible con system/sepolicy/public, este método no está disponible para política de proveedor de servicios en la nube. Un tipo público existente debe proporcionar el acceso.

Ejemplo: Un cambio en un proceso del sistema (AOSP o no) debe cambiar la forma en que interactúa con un nuevo componente de proveedor que no pertenece al AOSP.

La política en la imagen del sistema se debe escribir sin conocer las personalizaciones de los proveedores. Por lo tanto, la política relacionada con interfaces específicas en AOSP a través de atributos en sistema/sepolicy/público para que la política del proveedor pueda aceptar la futura política del sistema que use estos atributos. Sin embargo, las extensiones de atributos de system/sepolicy/public no se compatible, por lo que todas las políticas que determinan cómo interactúan los componentes del sistema con nuevos componentes de proveedores (que no están manejados por atributos que ya presentes en system/sepolicy/public del AOSP) deben estar en device/manufacturer/device-name/sepolicy Esto significa que los tipos de sistema no pueden cambiar el acceso permitido a tipos de proveedores como parte de una OTA solo de framework.