2 votos

Cómo SElinux protege a Android de las root

Sé que cuando enraizamos ejecutamos un script y usamos un cosa que ya es Root y le dice que se ejecute si ejecuta el script como Root y luego arraiga el teléfono así que ¿cómo ayuda SElinux a protegerse contra él

Ejemplo He explotado el kernel para ejecutar el script como Root que se ejecutará en el dominio del kernel que ya es Root por lo que el ejecutará el script como Root y dará privilegios Root así que ¿cómo se protege SElinux contra ello?

Resumen: Explotar es una explotación de cualquier sistema para rootear script script es un script que se pasará a la zona explotada para que pueda ejecutarse como root y root del sistema

Así que si lo exploto y paso el script cómo SElinux protegerá contra ella?

5voto

Gokul NC Puntos 34

SELinux depende de las etiquetas para hacer coincidir las acciones y las políticas. Las etiquetas determinan lo que está permitido. Los sockets, archivos y procesos tienen etiquetas en SELinux. Las decisiones de SELinux se basan fundamentalmente en las etiquetas asignadas a estos objetos y en la política que define cómo pueden interactuar. En SELinux, una etiqueta adopta la forma: usuario:rol:tipo:mls_nivel, donde el tipo es el componente principal de las decisiones de acceso, que puede ser modificado por los componentes de las otras secciones que componen la etiqueta. Los objetos se mapean a clases y los diferentes tipos de acceso para cada clase se representan por medio de permisos.

Las reglas de la política vienen en la forma: permitir tipos de dominios:clases de permisos;, donde:

Dominio - Una etiqueta para el proceso o conjunto de procesos. También llamado tipo de dominio, ya que es sólo un tipo para un proceso. Tipo - Una etiqueta para el objeto (por ejemplo, archivo, socket) o conjunto de objetos. Clase - El tipo de objeto (por ejemplo, archivo, socket) al que se accede. Permiso - La operación (por ejemplo, lectura, escritura) que se está realizando. Y así un ejemplo de uso de esto seguiría la estructura:

permitir appdomain app_data_file:file rw_file_perms;

Esto dice que todos los dominios de aplicación pueden leer y escribir archivos etiquetados como app_data_file. Tenga en cuenta que esta regla se basa en las macros definidas en el archivo global_macros, y otras macros útiles también se pueden encontrar en el archivo te_macros, ambos se pueden encontrar en el directorio external/sepolicy en el árbol de fuentes de la AOSP. Los macros se proporcionan para agrupaciones comunes de clases, permisos y reglas, y deben utilizarse siempre que sea posible para ayudar a reducir la probabilidad de fallos debidos a la denegación de permisos relacionados.

Además de enumerar individualmente los dominios o tipos en una regla, también se puede hacer referencia a un conjunto de dominios o tipos mediante un atributo. Un atributo es simplemente un nombre para un conjunto de dominios o tipos. Cada dominio o tipo puede asociarse con cualquier número de atributos. Cuando se escribe una regla que especifica un nombre de atributo, ese nombre se expande automáticamente a la lista de dominios o tipos asociados al atributo. Por ejemplo, el atributo de dominio se asocia con todos los dominios de proceso, y el atributo de tipo_archivo se asocia con todos los tipos de archivo.

Use la sintaxis anterior para crear reglas avc que comprenden la esencia de una política SELinux. Una regla toma la forma:

<rule variant> <source_types> <target_types> : <classes> <permissions>

La regla indica lo que debe ocurrir cuando un sujeto etiquetado con cualquiera de los tipos_fuente intenta una acción correspondiente a cualquiera de los permisos sobre un objeto con cualquiera de las clases de clase que tiene cualquiera de la etiqueta de los tipos_objetivo. El ejemplo más común de una de estas reglas es una regla de permiso, por ejemplo

permite el dominio null_device:chr_file { open };

Esta regla permite a un proceso con cualquier dominio asociado al atributo 'domain' realizar la acción descrita por el permiso 'open' sobre un objeto de clase 'chr_file' (archivo de dispositivo de caracteres) que tiene la etiqueta de tipo 'target_type' de 'null_device'. En la práctica, esta regla puede ampliarse para incluir otros permisos:

allow domain null_device:chr_file { getattr open read ioctl lock apéndice escribir};

Cuando se combina con el conocimiento de que "dominio" es un atributo asignado a todos los dominios de proceso y que null_device es la etiqueta del dispositivo de caracteres /dev/null, esta regla permite básicamente leer y escribir en /dev/null.

Un dominio corresponde generalmente a un proceso y tendrá una etiqueta asociada a él.

Por ejemplo, una aplicación típica de Android se ejecuta en su propio proceso y tiene la etiqueta de untrusted_app que le otorga ciertos permisos restringidos.

Las aplicaciones de plataforma incorporadas al sistema funcionan bajo una etiqueta separada y se les otorga un conjunto distinto de permisos. Las aplicaciones UID del sistema que forman parte del núcleo del sistema Android se ejecutan bajo la etiqueta system_app para obtener otro conjunto de privilegios.

Nunca se debe permitir el acceso a las siguientes etiquetas genéricas directamente a los dominios, sino que se debe crear un tipo más específico para el objeto o los objetos:

socket_device dispositivo block_device servicio_por_ defecto archivo_de_sistema_de_datos tmpfs

Fuente: Conceptos de SELinux
Para más detalles, ver: Seguridad mejorada de Linux en Android
Implementación de SELinux

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X