Solución:
La raíz es el usuario 0
La clave es el ID de usuario 0. Hay muchos lugares en el kernel que verifican el ID de usuario del proceso de llamada y otorgan permiso para hacer algo solo si el ID de usuario es 0.
El nombre de usuario es irrelevante; el kernel ni siquiera conoce los nombres de usuario.
El mecanismo de permisos de Android es idéntico a nivel de kernel pero completamente diferente a nivel de aplicación. Android tiene un usuario root (UID 0), como cualquier otro sistema basado en un kernel de Linux. Sin embargo, Android no tiene cuentas de usuario, y en la mayoría de las configuraciones no permite que el usuario (como en el ser humano que opera y posee el dispositivo) realice acciones como usuario root. Un Android “rooteado” es una configuración que permite al propietario / usuario del dispositivo realizar acciones como root.
Cómo funciona setuid
Un ejecutable setuid se ejecuta como el usuario propietario del ejecutable. Por ejemplo, su se establece y es propiedad de root, por lo que cuando cualquier usuario lo ejecuta, el proceso que se ejecuta su se ejecuta como usuario root. El trabajo de su es verificar que el usuario que lo llama puede usar la cuenta raíz, ejecutar el comando especificado (o un shell si no se especifica ningún comando) si esta verificación tiene éxito, y salir si esta verificación falla. Por ejemplo, su podría pedirle al usuario que demuestre que conoce la contraseña de root.
Más detalladamente, un proceso tiene tres ID de usuario: el eficaz UID, que se utiliza para controles de seguridad; los verdadero UID, que se utiliza en algunas comprobaciones de privilegios, pero es principalmente útil como copia de seguridad de la ID de usuario original y la ID de usuario guardada que permite que un proceso cambie temporalmente su UID efectiva a la ID de usuario real y luego vuelva a la anterior. UID efectivo (esto es útil, por ejemplo, cuando un programa setuid necesita acceder a un archivo como usuario original). La ejecución de un ejecutable setuid establece el UID efectivo en el propietario del ejecutable y conserva el UID real.
Ejecutar un ejecutable setuid (y mecanismos similares, por ejemplo, setgid) es la única forma de elevar los privilegios de un proceso. Casi todo lo demás solo puede disminuir los privilegios de un proceso.
Más allá de Unix tradicional
Hasta ahora describí los sistemas Unix tradicionales. Todo esto es cierto en un sistema Linux moderno, pero Linux trae varias complicaciones adicionales.
Linux tiene un sistema de capacidad. ¿Recuerda que dije que el kernel tiene muchas comprobaciones en las que solo se permiten los procesos que se ejecutan como ID de usuario 0? De hecho, cada verificación tiene su propia capacidad (bueno, no del todo, algunas verificaciones usan la misma capacidad). Por ejemplo, existe una capacidad para acceder a sockets de red sin procesar y otra capacidad para reiniciar el sistema. Cada proceso tiene un conjunto de capacidades junto con sus usuarios y grupos. El proceso pasa la verificación si se está ejecutando como usuario 0 o si tiene la capacidad que corresponde a la verificación. Un proceso que requiere un privilegio específico puede ejecutarse como un usuario no root pero con la capacidad requerida; esto limita el impacto si el proceso tiene un agujero de seguridad. Un ejecutable se puede configurar como una o más capacidades: esto es similar a setuid, pero funciona en el conjunto de capacidades del proceso en lugar del ID de usuario del proceso. Por ejemplo, ping solo necesita sockets de red sin procesar, por lo que se puede configurar CAP_NET_RAW en lugar de setuid root.
Linux tiene varios módulos de seguridad, el más conocido es SELinux. Los módulos de seguridad introducen controles de seguridad adicionales, que pueden aplicarse incluso a los procesos que se ejecutan como root. Por ejemplo, es posible (¡no fácil!) Configurar SELinux para ejecutar un proceso como ID de usuario 0 pero con tantas restricciones que en realidad no puede hacer nada.
Linux tiene espacios de nombres de usuario. Dentro del kernel, un usuario no es solo una identificación de usuario, sino un par que consta de una identificación de usuario y un espacio de nombres. Los espacios de nombres forman una jerarquía: un espacio de nombres secundario refina los permisos dentro de su principal. El usuario todopoderoso es el usuario 0 en el espacio de nombres raíz. El usuario 0 en un espacio de nombres tiene poderes solo dentro de ese espacio de nombres. Por ejemplo, el usuario 0 en un espacio de nombres de usuario puede suplantar a cualquier usuario de ese espacio de nombres; pero desde el exterior, todos los procesos en ese espacio de nombres se ejecutan como el mismo usuario.
En Linux hay 4 UID: RUID (verdadero), EUID (eficaz), SUID (salvado), FSUID (sistema de archivos).
Estos no son más que números y son propiedades de procesos, que se almacenan en un bloque de control en la tabla de procesos del Kernel.
El UID '0' tiene una característica especial, ya que denota al usuario root, que generalmente tiene derechos de acceso ilimitados.
su y sudo son programas para cambiar los derechos de acceso efectivos del usuario, iniciando un nuevo subproceso con el EUID establecido en el nuevo UID a través del bit SetUID de su. Este proceso su luego genera un nuevo shell nuevamente en un nuevo subproceso con los 4 UID establecidos en el nuevo valor de UID.
El siguiente ejemplo debería demostrar esto. Digamos un usuario rda está conectado a través de una terminal ssh. ps fax mostrará los siguientes procesos involucrados:
472 ? Ss 0:00 /usr/sbin/sshd -D
9151 ? Ss 0:00 _ sshd: rda [priv]
9153 ? S 0:00 | _ sshd: [email protected]/1
9154 pts/1 Ss+ 0:00 | _ -bash
4 procesos, el demonio ssh, dos procesos para la sesión ssh (¿y terminal?), El último proceso es un shell de inicio de sesión (indicado por un - en frente de bash)
ps faw -eo euser,ruser,suser,fuser,f,comm mostrará los UID de los procesos:
EUSER RUSER SUSER FUSER F COMMAND
...
root root root root 4 sshd
root root root root 4 _ sshd
rda rda rda rda 5 | _ sshd
rda rda rda rda 0 | _ bash
Invocando su seguido de una autenticación exitosa dará como resultado lo siguiente:
EUSER RUSER SUSER FUSER F COMMAND
...
root root root root 4 sshd
root root root root 4 _ sshd
rda rda rda rda 5 | _ sshd
rda rda rda rda 0 | _ bash
root rda root root 4 | _ su
root root root root 4 | _ bash
El proceso ‘bash’ inicia un nuevo proceso hijo ‘su’ con EUID establecido por el bit SetUID en '0' (root), RUID todavía está configurado en el UID de rda en este punto. El proceso ‘su’ vuelve a iniciar un nuevo proceso hijo con un nuevo shell, otorgando al usuario acceso de root (RUID ahora está configurado en '0' también). El usuario permanece en su directorio de trabajo y el nuevo shell usará el mismo entorno que el shell padre, por ejemplo:
server:/home/rda# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
server:/home/rda# pwd
/home/rda
La cáscara se puede cerrar con exit y el usuario estará en el shell padre con sus derechos de acceso originales.
La situación es diferente si se invoca ‘su’ con un guión '-' parámetro:
[email protected]:~$ su -
Password:
server:~# echo $PATH
/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
server:~# pwd
/root
El entorno del shell ha cambiado, ya que el nuevo shell es un shell de inicio de sesión, consulte '-su', que ejecuta algunos scripts de configuración adicionales:
9151 ? Ss 0:00 _ sshd: rda [priv]
9153 ? S 0:00 | _ sshd: [email protected]/1
9154 pts/1 Ss 0:00 | _ -bash
9613 pts/1 S 0:00 | _ su -
9614 pts/1 S+ 0:00 | _ -su
Un shell de inicio de sesión debe cerrarse con logout.
En teoría, creo que es posible evitar que el usuario obtenga privilegios elevados eliminando sudo y su y no dan la posibilidad de iniciar sesión en el sistema directamente (a través de terminal, ssh, etc.) y sin acceso físico al dispositivo.
Actualizar: Proceso de enraizamiento en Android
Como se explica en detalle aquí, los posibles métodos para rootear un dispositivo Android dependen de la cargador de arranque y el Propiedad del sistema Androidro.secure.
El objetivo es siempre el mismo, para instalar el su binario en /system y hazlo setuid(0).
Dispositivo con cargador de arranque desbloqueado:
Tire de la ROM de stock con dd desde el dispositivo, agregue su, reempaquetar (o descargar una ROM modificada), reiniciar el dispositivo en modo flash y flashear la ROM modificada.
Dispositivo con ro.secure = 0:
Esta propiedad del sistema controla si los comandos escritos en un adb shell se ejecutan como rootro.secure=0) o como usuario sin privilegios (ro.secure=1) El valor de ro.secure se establece en el momento del arranque desde el default.prop archivo en el root directorio, al que solo puede acceder el usuario raíz y, por lo tanto, seguro.
En la mayoría de los casos esto ro.secure se establece en 1, pero algunos fabricantes lo configuran 0. Esto se puede verificar ejecutando el comando getprop ro.secure en un emulador de terminal en el dispositivo o en un shell de adb. Si está configurado en 0, rootear es bastante fácil, conéctelo a una computadora, ejecute adb, montar /system como lectura-escritura, instalar su.
Dispositivo con cargador de arranque bloqueado:
Dicho dispositivo tiene una recuperación que no permite actualizar una ROM personalizada, que no ha sido firmada por el fabricante. La única forma de obtener acceso de root en esta situación es explotando una vulnerabilidad de seguridad en uno de los procesos del sistema en ejecución, que se ejecutan en modo privilegiado, y hackearlo para permitir la ejecución de “código arbitrario”. Este código generalmente se monta /system e instala su permanentemente.
En general, es solo que el uid efectivo es 0. El bit “setuid” en los ejecutables realmente establece el eficaz uid del proceso. Si el uid efectivo no es cero y el uid real no es cero, el programa se está ejecutando como un usuario “sin privilegios”. Se aplica lo siguiente:
Los procesos sin privilegios solo pueden establecer el ID de usuario efectivo en el ID de usuario real, el ID de usuario efectivo o el ID de usuario configurado guardado. Los usuarios sin privilegios solo pueden establecer el ID de usuario real en el ID de usuario real o el ID de usuario efectivo.
En lo que respecta a Android, no, no creo que se elimine sudo y su es suficiente – si cualquier programa puede tener el bit seteuid establecido, ese programa puede potencialmente ejecutarse con uid = 0. Si existe alguna posibilidad de tener acceso al sistema de archivos interno como root en cualquier momento, entonces dicho programa puede ser introducido y el acceso a la raíz es factible.
valoraciones y reseñas
Te invitamos a auxiliar nuestro estudio escribiendo un comentario o puntuándolo te damos la bienvenida.