Dado que Android está basado en el kernel de Linux, obtener acceso Root ejecutando /system/xbin/su - como se puede hacer en un sistema Linux - solía funcionar en los buenos tiempos, pero no ahora. La historia es un poco retorcida.
¿QUÉ ES EL SUID?
Lo especial de /system/xbin/su no es que esté en /system partición, pero el set-user-ID-root (SUID) El bit establecido en este binario lo hace especial. SUID ( S y propietario U ser ID up on execution) es un tipo especial de permiso en el kernel de Linux que otorga los permisos del propietario del archivo al nuevo proceso en lugar de heredar los permisos del proceso padre que lo ejecuta. Dado que el propietario de /system/xbin/su es Root (UID 0), puede cambiar el UID efectivo del proceso a 0 cuando se ejecuta, permitiendo así que el proceso que llama tenga acceso a Root.
Esto forma parte del Control de Acceso Discrecional (DAC); uno de Características de seguridad del núcleo de Linux .
CONTROL DE ACCESO OBLIGATORIO (MAC):
Implementado desde KitKat, SELinux puede controlar quién ejecuta su binario, mediante la definición de reglas de Vector de Acceso:
Objeto: /system/xbin/su u:object_r:su_exec:s0
Asunto: service adbd /system/bin/adbd --root_seclabel=u:r:su:s0
Y regula algo así como: allow su su_exec : file { read getattr map execute entrypoint open }
Es evidente que sólo adb daemon cuando se ejecuta como Root, será capaz de ejecutar su binario. Pero adbd no puede ser ejecutado como Root ( 1 , 2 ) sobre el final el usuario construye , ni se incluye el binario su en user construye. Así que, /system/xbin/su está pensado sólo para que los desarrolladores puedan depurar eng inercia o userdebug construye una ROM.
Del mismo modo, algunos otros programas como estado de volcado y cáscara puede hacer transición de tipo para correr con el contexto u:r:su:s0 mientras se ejecuta su para fines de depuración, ya que tiene mencionado .
¿Cómo restringe Android el acceso a root?
Dejando de lado SELinux, en la construcción de una ROM destinada a usuarios finales, colocar su en /system no dará ninguna ventaja, incluso con set-user-ID-root . Una aplicación normal no puede elevar sus privilegios a Root ejecutando su porque:
- A partir de Jelly Bean Android cambió a las capacidades de archivo (una capacidad es un subconjunto de los privilegios de Root) en lugar de confiar en
set-user-ID tipo de vulnerabilidades de seguridad. Un mecanismo más seguro: Capacidades ambientales también se ha introducido en Android Oreo.
- Los demonios y servicios del sistema pueden hacer uso de las capacidades de los archivos para obtener capacidades de proceso (véase en Transformación de las capacidades durante la ejecución ) pero las aplicaciones tampoco pueden hacerlo porque se ejecutan con el atributo de control de procesos
NO_NEW_PRIVS conjunto, ignorando set-user-ID así como las capacidades de los archivos. El SUID también se ignora al montar /system y /data con nosuid para todas las aplicaciones.
- El UID sólo puede cambiarse si el proceso de llamada tiene SETUID/SETGID en su conjunto Bounding (una de las 5 categorías de capacidades que puede tener un proceso). Pero las aplicaciones de Android están hechas para ejecutarse con todas las capacidades ya caídas en todos los conjuntos.
- A partir de Oreo, la capacidad de las apps para cambiar el UID/GID se ha suprimido aún más por bloquear ciertas llamadas al sistema utilizando filtros seccomp .
El demonio ADB, sin embargo, se ejecuta con CAP_SETUID y CAP_SETGID . Pero adb shell también no puede conseguirnos capacidades ejecutando un SUID-Root su binario porque NOROOT y NO_SETUID_FIXUP los bits de seguridad están activados en adbd proceso.
Las llamadas al sistema utilizadas en estos métodos de sandboxing: cap_set_proc , setresuid , setresgid , sys_seccomp , prctl (CAPBSET_DROP, SET_NO_NEW_PRIVS, SET_SECUREBITS, SET_SECCOMP) forman parte de Minijail .
¿CÓMO OBTENER ACCESO A root EN ANDROID?
Así que si queremos tener privilegios con UID 0 y todas las 38 capacidades del kernel de Linux, necesitamos una solución de rooting que pueda lidiar con todas las medidas de seguridad descritas anteriormente. Dado que la solución autónoma su binarios dejaron de funcionar con el lanzamiento de Jelly Bean, se hizo una transición al modo su daemon .
Ahora, en un teléfono rooteado, un demonio con todos los privilegios se ejecuta desde el inicio del proceso de arranque (de hecho init se sustituye). Cuando una aplicación necesita acceso a root, ejecuta su binario proporcionado por la solución del rooting . Este su no cambia el UID/GID por sí mismo, sino que sólo se conecta al demonio del superusuario a través de un socket UNIX y pide que se proporcione a la aplicación solicitante un shell Root con todas las capacidades. Para interactuar con el usuario para conceder/denegar su de las aplicaciones, su daemon se conecta con una aplicación que puede mostrar las indicaciones de la interfaz de usuario. El demonio su crea una base de datos de permisos concedidos/denegados para su uso futuro.
Además de eso, las denegaciones de SELinux también se manejan definiendo las reglas de permiso de la política de SELinux cuando se rootea el teléfono.
Los nuevos métodos de Root como Magisk funcionan en modo sin sistema, es decir, sin modificar /system partición. Sólo se modifica la partición de arranque -que contiene el kernel y el initramfs- para inyectar el servicio su daemon y las nuevas políticas de SELiux. Un gestor de arranque bloqueado no arrancará modificado boot.img , por lo que hay que desbloquear el bootloader. Para más detalles sobre esto, ver Desbloqueo del Bootloader . Sin embargo, ha habido algunos hacks del rooting que han funcionado saltándose las implementaciones de seguridad descritas anteriormente sin recurrir a la forma adecuada del rooting. La mayoría de estos exploits y vulnerabilidades en el sistema operativo Android se han solucionado con el tiempo. Aquí hay una buena redactar sobre este tema.
Así, colocando su binario bajo /system o cualquier otro lugar no dará ningún beneficio.
PS: Por favor, ignora tantos enlaces, son para mi propia referencia futura.
