USUARIO DE LA RAZÓN Y SELINUX:
Usuario root (con UID 0) es el superusuario en la implementación del Control de Acceso Discrecional (DAC) de los sistemas operativos *NIX. DAC es permitido por defecto Es decir, cualquiera puede acceder a cualquier cosa a menos que los UID, GID y el modo de permiso restrinjan algo. Así que root puede hacer cualquier cosa porque es el núcleo SUPER USUARIO que no se le niega nada.
SELinux es el Control de Acceso Obligatorio (MAC) que es denegado por defecto Es decir, nadie puede acceder a nada a menos que se defina una regla de política para permitir el acceso. Así que no hay SUPER CONTEXTO que puede hacer cualquier cosa, sea cual sea el UID. Tienes que definir una regla para permitir cualquier operación que quieras realizar en tu dispositivo.
Tenga en cuenta que los controles de acceso (DAC o MAC) son aplicados por el kernel en el back end, que es el verdadero sistema operativo .
¿Cómo se aplica SELINUX en Android?
Las reglas de política de SELinux se definen al construir la ROM y se guardan como un archivo binario /sepolicy (o como split-policy ). Esta política es cargada por init (el primer proceso iniciado en el kernel Dominio SELinux ) antes de iniciar cualquier servicio/demonio/proceso en el arranque. El núcleo se inicia con SELinux permissive si se construye con la opción SECURITY_SELINUX_DEVELOP=y (que es el valor por defecto, como se discute aquí y aquí ). Después de cargar la política, init - cuando todavía se ejecuta con el contexto del kernel - establece SELinux enforcing (dependiendo del tipo de construcción de la ROM y del parámetro del núcleo androidboot.selinux ( 0 ) ) y luego cambia al contexto propio de init. A partir de aquí, incluso init no está permitido por la política volver a permissive modo ( 1 , 2 ) . La política no puede ser modificada ni siquiera por root usuario ( 3 ) .
Sin embargo, hay una excepción a dichas reglas. En userdebug o eng construye, u:r:su:s0 - que es el contexto adb shell obtiene cuando adbd se ejecuta como Root ( 4 ) o cuando /system/xbin/su se ejecuta ( 5 ) - puede hacer cualquier cosa, incluido el establecimiento de SELinux permisivo ( 6 ) .
Pero en una producción final ( user ) de la ROM, la única manera de setenforce 0 o modificar la política es tomar el control del proceso de arranque antes de que SELinux se establezca enforcing por init . Eso es lo que hacen las soluciones del rooting como Magisk al sustituir/Parcheando /init y /sepolicy en el disco RAM ( boot.img ). Magisk ejecuta procesos Root con contexto u:r:magisk:s0 que está permitido por la política parcheada para hacer cualquier cosa.
Una vez que tenga derechos (otorgados por DAC y MAC) para jugar con la política de SELinux, puede definir nuevas reglas de política de SELinux como se explica aquí .
Pasando a su pregunta:
selinux está haciendo cumplir pero quiero que sea permisivo lo que nunca sucederá con el kernel de stock
No. SELinux está configurado enforcing por init , no por el núcleo, excepto si se construye con SECURITY_SELINUX_ENFORCING=y opción ( 7 ) .
un contexto superior para hacer cosas como supolicy --live para parchear la política de selinux
No hay ningún contexto superior que pueda hacer nada. No se puede establecer el modo permissive y no puede parchear la política en user construye.
¿cuál es el contexto (de destino) que permitirá a cualquier otro contexto (de origen) ejecutar el script?
Como se ha dicho, no hay más alto contexto de la fuente que puede hacer cualquier cosa a los demás. De la misma manera, no hay baja contexto objetivo que permite a los demás hacer cualquier cosa.
También cuando se ejecuta un script, no hay necesariamente un único contexto de destino. Cada archivo que el script utiliza (binarios, configuraciones, registros, etc.) puede tener su etiqueta de contexto diferente. Y typetransitions también puede cambiar los contextos de origen.
Si desea modificar la política, puede obtener todos los avc denials del registro del kernel y luego definir nuevas reglas de SELinux en consecuencia:
~# dmesg -w | grep avc:
Solución:
Como ya está en eng build, sólo sustituye el binario del kernel ( zImage ) en su boot.img si quiere reemplazar el kernel. De lo contrario, te quedas atascado usando init y sepolicy de boot.img de un user construir.
En eng construir:
/init no establece SELinux enforcing en el arranque ( 8 )/sepolicy permite a Root adb shell para hacer cualquier cosa, incluyendo setenforce y load_policy como se ha explicado anteriormente
Si su núcleo está construido con SECURITY_SELINUX_ALWAYS_ENFORCE no se puede configurar SELinux permissive una vez que se ha establecido enforcing ( 9 ) .
RELACIONADO:
