Sé que cuando rooteamos ejecutamos un script y usamos algo que ya es root y le decimos que se ejecute si ejecuta el script como root y luego rootea el teléfono, entonces, ¿cómo ayuda SElinux a protegerlo?
Ejemplo Exploté el kernel para ejecutar el script como root, se ejecutará en el dominio del kernel que ya es root, por lo que ejecutará el script como root y otorgará privilegios de root, entonces, ¿cómo se protege SElinux contra él?
Resumen: Exploit es cualquier exploit en el sistema para rootear. Script script es un script que se pasará al área explotada para que pueda ejecutarse como root y rootear el sistema.
Entonces, si lo exploto y paso el script, ¿cómo se protegerá SElinux contra él?
SELinux depende de las etiquetas para hacer coincidir acciones y 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 la política que define cómo pueden interactuar. En SELinux, una etiqueta toma 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 otros componentes de las secciones que componen la etiqueta. Los objetos están asignados a clases y los diferentes tipos de acceso para cada clase están representados por permisos.
Las reglas de la política vienen en la forma: permitir tipos de dominios:permisos de clases;, donde:
Dominio: una etiqueta para el proceso o conjunto de procesos. También llamado tipo de dominio, ya que es solo un tipo para un proceso. Tipo: una etiqueta para el objeto (p. ej., archivo, socket) o conjunto de objetos. Clase: el tipo de objeto (p. ej., archivo, socket) al que se accede. Permiso: la operación (por ejemplo, lectura, escritura) que se está realizando. Y entonces, un ejemplo de uso de esto seguiría la estructura:
permitir appdomain app_data_file:archivo rw_file_perms;
Esto dice que todos los dominios de aplicaciones pueden leer y escribir archivos etiquetados app_data_file. Tenga en cuenta que esta regla se basa en las macros definidas en el archivo global_macros, y también se pueden encontrar otras macros útiles en el archivo te_macros, los cuales se pueden encontrar en el directorio external/sepolicy en el árbol de fuentes de AOSP. Se proporcionan macros para agrupaciones comunes de clases, permisos y reglas, y deben utilizarse siempre que sea posible para ayudar a reducir la probabilidad de fallas debido a la denegación de permisos relacionados.
Además de enumerar dominios o tipos individualmente en una regla, también se puede hacer referencia a un conjunto de dominios o tipos a través de un atributo. Un atributo es simplemente un nombre para un conjunto de dominios o tipos. Cada dominio o tipo se puede asociar 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 con el atributo. Por ejemplo, el atributo de dominio está asociado con todos los dominios de proceso y el atributo file_type está asociado con todos los tipos de archivos.
Utilice la sintaxis anterior para crear reglas avc que constituyan la esencia de una política de SELinux. Una regla toma la forma:
<rule variant> <source_types> <target_types> : <classes> <permissions>
La regla indica lo que debe suceder cuando un sujeto etiquetado con cualquiera de los tipos de origen intenta una acción correspondiente a cualquiera de los permisos en un objeto con cualquiera de las clases que tiene alguna de las etiquetas de tipos de destino. El ejemplo más común de una de estas reglas es una regla de permiso, por ejemplo:
permitir dominio null_device:chr_file {abrir};
Esta regla permite que un proceso con cualquier dominio asociado con el atributo 'dominio' realice la acción descrita por el permiso 'abrir' en un objeto de clase 'chr_file' (archivo de dispositivo de caracteres) que tiene la etiqueta target_type de 'null_device'. En la práctica, esta regla puede extenderse para incluir otros permisos:
permitir dominio null_device:chr_file { getattr open read ioctl lock append write};
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 para el dispositivo de caracteres /dev/null, esta regla básicamente permite leer y escribir en /dev/null.
Un dominio generalmente corresponde 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 integradas en el sistema se ejecutan bajo una etiqueta separada y se les otorga un conjunto distinto de permisos. Las aplicaciones UID del sistema que forman parte del sistema Android central se ejecutan bajo la etiqueta system_app para obtener otro conjunto de privilegios.
El acceso a las siguientes etiquetas genéricas nunca debe permitirse directamente a los dominios; en su lugar, se debe crear un tipo más específico para el objeto u objetos:
dispositivo_socket dispositivo dispositivo_bloque servicio_predeterminado archivo_datos_sistema tmpfs
Fuente: Conceptos de SELinux
Para obtener más detalles, consulte: Linux con seguridad mejorada en Android
Implementación de SELinux
culona74