¿Cómo proporciona SuperSu el privilegio de root?

SuperSU ya no se desarrolla activamente, el nuevo estándar que prevalece es Magisk, que originalmente se basaba en SuperSU (ideas y quizás también algo de código) pero ahora ha avanzado mucho. Así que mejor ir a por una nueva solución de código abierto mantenida activamente siempre que sea posible. O si quieres algo de aventura, prueba esto: ¿Cómo hacer root manualmente un teléfono? .

Mi respuesta a ¿Cómo funciona Magisk? cubre casi todos los aspectos internos de SuperSU, también algunos detalles extra que no son aplicables a SuperSU. Vamos a mantenerlo simple.

USUARIO root (UID 0 ):

Android se basa en el kernel de Linux que, cuando se inicia en el arranque del dispositivo, se ejecuta como usuario Root. Espacio del núcleo es invisible para nosotros - el espacio de usuario . init es el primer proceso iniciado por el kernel que podemos ver, también se ejecuta con acceso Root. Inicia muchos servicios/demones (el SO), muchos de ellos también se ejecutan con privilegios Root. Finalmente cuando todos los procesos requeridos están en marcha, init nos lleva a un proceso no root (sin privilegios) - un shell en los sistemas operativos Linux estándar, un Aplicación de lanzamiento o Pantalla de bloqueo (que también es Interfaz del sistema app) en Android. Root es el querido usuario del kernel - el Súper Usuario - identificado por U ser ID 0 . El kernel nunca le restringe hacer ningún daño o bien a nada en el dispositivo. A los usuarios sin privilegios se les asignan UIDs 1 a 65534 (normalmente). Android divide estos UIDs para diferentes categorías de aplicaciones y procesos como se explica aquí . Cada proceso y cada archivo tiene un UID , G roup ID , complementario grupos y permiso modo . Estos cuatro parámetros rigen la forma en que un proceso accede a otros procesos y archivos. Todo este fenómeno se denomina D iscrecional A cceso C ontrol.

¿CÓMO OBTIENEN LAS APPS EL ACCESO A LA RAZÓN?

Si un proceso sin privilegios quiere acceder a algún archivo o realizar alguna acción que sólo está permitida al usuario Root, el primero tiene que cambiar al segundo. Esto se hace ejecutando un archivo (normalmente su ) que es set-user-id-Root o tiene setuid / segid archivo capacidades . Una capacidad es un subconjunto de las autoridades del usuario Root. El archivo ejecutado hace setuid syscall para que el kernel eleve el estado no privilegiado a privilegiado. Esto es una simplificación, en realidad hay muchos otros factores involucrados. Pero en Android, las aplicaciones se ejecutan dejando caer todas las capacidades y privilegios de tal manera que no pueden elevar sus privilegios de ninguna manera (excluyendo las vulnerabilidades). Así que la aplicación sin privilegios solicita a algún otro proceso privilegiado ya en ejecución que realice la tarea privilegiada en su nombre. El proceso privilegiado se llama daemonsu (o magiskd ) y la solicitud se reenvía cuando una aplicación ejecuta el su binario que interactúa con la aplicación SuperSU para pedir permiso al usuario humano.

SELINUX:

Además de DAC, Android también hace uso de SELinux - a M andatorio A cceso C ontrol. Al igual que DAC, cada proceso y cada archivo es etiquetado con un contexto SELinux y se define una política para permitir una amplia gama de interacciones entre contextos/etiquetas. La política no contiene Supercontexto por lo que todos los procesos (incluso los que se ejecutan con UID 0 ) tiene algunas limitaciones. Pero daemonsu necesita ser ejecutado con un contexto completamente irrestricto que tiene que ser definido antes de que SELinux sea configurado enforcing (por init en la fase de arranque muy temprana) porque después no hay forma de configurarlo permissive o modificar la política. Algunos proveedores construyen sus núcleos sin SECURITY_SELINUX_DEVELOP , por lo que SELinux es reforzado por el kernel - incluso antes. En este caso el kernel necesita ser reconstruido/parchado. Ver detalles en esta respuesta .

PROCESO DE ENRAIZAMIENTO

Cuando el SuperSU.zip es flasheado:

• Parchea /sepolicy con un archivo totalmente permisivo u:r:supersu:s0 contexto ( supersu puede ser diferente, no puedo recordar lo que SuperSU utilizado en las últimas versiones, Magisk ahora utiliza u:r:magisk:s0 ).
• Inyecta un init servicio a /init.rc archivo que comienza daemonsu con UID/GID 0 y el contexto de SELinux u:r:supersu:s0 después de /data está montado (o incluso antes).

Ambos sepolicy y init.rc archivos han sido parte de ramdisk dentro de boot.img (que también contiene el binario del núcleo), pero con Treble, SAR y A/B Las particiones pueden estar en diferentes lugares. Así que Magisk utiliza diferentes enfoques para diferentes dispositivos, pero el concepto es el mismo.

Ambos pasos también pueden ser sustituidos por la sustitución del /init binario con un init que se encarga del proceso de arranque, parchea sepolicy y se inicia el servicio sobre la marcha antes de ejecutar el init .

Otras cosas que están directamente relacionadas con el proceso de rooting incluyen el desbloqueo del bootloader, boot.img desempaquetar/reempaquetar, desactivar el arranque verificado ( dm-verity ) y FDE/FBE , Parcheando el núcleo para arrancar diferente init (o para desactivar los mecanismos de seguridad específicos del proveedor), el rooting sin sistema, la (des)configuración de las propiedades de Android, los directorios de montaje vinculante, el aislamiento de los espacios de nombres de montaje, etc.