Un breve análisis de cómo Android garantiza la seguridad en diferentes niveles
El mecanismo de seguridad en Android se puede implementar básicamente desde dos aspectos: 1. Sandbox de la aplicación 2. Restricciones de permisos
Primero comprenda los conocimientos básicos:
Android es un sistema operativo por capas, que consta de 4 capas: kernel de Linux, espacio de usuario nativo, marco de trabajo de Android, aplicación
El principio de seguridad central de Android es que las aplicaciones no deben dañar los recursos del sistema operativo, los usuarios y otras aplicaciones. .
1.Capa del Kernel de Linux
El kernel de Linux es responsable de configurar el sandbox de la aplicación y regular algunos permisos.
Configure un sandbox de aplicación para cada aplicación. Cada aplicación se ejecuta en su propio sandbox. Durante el proceso de instalación, a cada paquete se le asignará un UID (identificador de usuario) y un GID (identificador de grupo) únicos. y cambios dentro del ciclo de vida de la aplicación del dispositivo. Por tanto, cada aplicación tiene un usuario de Linux correspondiente. El nombre de usuario sigue el formato app_x y el UID del usuario es igual a Process.FIRST_APPLICATION_UID+x. Debido a que cada aplicación tiene su propio UID y GID, el kernel de Linux obliga a las aplicaciones a ejecutarse dentro de su propio espacio de direcciones aislado, y el kernel de Linux utiliza el UID y GID únicos de la aplicación para lograr una separación justa de recursos directamente para diferentes aplicaciones, y cada una Cada aplicación se basa en la autenticación del modelo de control de acceso opcional (DAC) de Linux. Además, las aplicaciones firmadas con el mismo certificado pueden compartir datos entre sí, pueden tener el mismo UID o incluso ejecutarse en el mismo proceso. Podemos usar el comando adb adb shell ps para ver información sobre todos los procesos en el teléfono.
Restringir el acceso de las aplicaciones a determinadas funciones del sistema asignando usuarios de Linux y propietarios de grupos a los componentes que implementan esa función. Utilice los permisos del sistema de archivos para acceder a archivos y controladores de dispositivos y restringir el acceso al proceso a ciertas funciones del dispositivo. El controlador de dispositivo /dev/cam pertenece al propietario raíz y al grupo propietario de la cámara, lo que significa que solo los procesos que se ejecutan como raíz o están incluidos en el grupo de cámaras pueden usar este controlador, que es lo que llamamos la función de cámara. Si acepta instalar una aplicación para usar la función de cámara, a la aplicación se le asignará un GID de grupo de Linux de cámara, lo que indica que la aplicación puede leer información del controlador del dispositivo /dev/cam Entre estas etiquetas de permiso y el grupo correspondiente. El mapeo entre se define en el archivo framework/base/data/etc/platform.xml.
2. Capa de espacio de usuario nativo
Construcción de la estructura del sistema de archivos y los permisos de archivos
La secuencia de inicio de los dispositivos Android se puede dividir aproximadamente en los siguientes pasos: Arranque Rom - Boot Loader - Linux Kernel - Init
Cuando el usuario enciende el teléfono, la CPU del dispositivo aún no se ha inicializado. En este caso, el procesador comienza a ejecutar comandos desde la dirección cableada que apunta al. dirección de escritura de la CPU donde se encuentra la ROM de arranque Proteger un fragmento de código en la memoria cuyo objetivo principal es conservar el medio donde se encuentra el Boot Loader (cargador de arranque). Una vez completada la detección, la ROM de arranque carga el cargador de arranque en la memoria y comienza a ejecutar el código de carga del cargador de arranque. El cargador de arranque es responsable de establecer la RAM externa, el sistema de archivos y el soporte de red. Después de eso, Linux comienza a cargarse, el kernel inicializa el entorno para ejecutar el código C, comienza a cargar controladores, montar sistemas de archivos y ejecutar procesos en el espacio de usuario. En Android, el primer proceso de usuario es init, que se inicia con privilegios de root (UID=0) y es el antepasado de todos los procesos.
init tiene un archivo de configuración init.rc, que predefine algunos eventos. Cuando init se está ejecutando, se ejecutará de acuerdo con sus eventos predefinidos. Es el principal responsable de crear la estructura básica del archivo, configurar los parámetros del kernel e iniciar el demonio ueventd y ServiceManager. El inicio, inicio del proceso Zygote, etc. El primer demonio es el demonio ueventd, que establece principalmente los propietarios y permisos de diferentes dispositivos. ServiceManager actúa como un índice de todos los servicios en Android. Zygote es el antepasado de todos los procesos y todas nuestras aplicaciones se derivan de Zygote.
/system, /data y /cache son los directorios principales del sistema de archivos de Android, que el programa init instala en puntos predefinidos. La partición /system contiene todo el sistema Android excepto el kernel de Linux. Esta carpeta contiene los subdirectorios /system/bin y system/lib, que contienen respectivamente los archivos ejecutables locales principales y las bibliotecas compartidas, así como todos los archivos preconstruidos por la imagen del sistema. Se aplica el sistema y la imagen se instala en modo de solo lectura, por lo que el contenido de esta partición no se puede cambiar en tiempo de ejecución. Dado que /system está montado como de solo lectura, no se puede usar para almacenar datos, por lo que una partición /data separada es responsable de almacenar datos del usuario o información que cambia con el tiempo. La partición /cache es responsable de almacenar datos y componentes de aplicaciones a los que se accede con frecuencia. Los permisos predeterminados para estas carpetas se deben definir en el momento de la compilación.
3. Capa del marco de trabajo de Android
La seguridad a nivel del marco de la aplicación se implementa mediante el monitor de referencia IPC.
Dado que las aplicaciones están en entornos sandbox separados, el cuadro se ejecuta. diferentes procesos con diferentes identidades de Linux, por lo que se necesita un marco de comunicación entre procesos (IPC) para gestionar el intercambio de datos y señales entre diferentes procesos. En Android, la comunicación entre procesos la implementa principalmente Binder, que es un marco especial rediseñado en Android para admitir la comunicación entre procesos. Proporciona gestión de todo tipo de procesos entre procesos en el sistema operativo Android. .
En Android, cada función clave de un servicio (un método del servicio) está protegida por una etiqueta especial llamada permiso. En otras palabras, antes de ejecutar dicha función, comprobará si al proceso Diao Hong se le han asignado permisos. Si tiene permiso, se permite la llamada; de lo contrario, se generará una excepción de control de seguridad. Debemos escribir los permisos correspondientes en AndroidManifest.xml, y los permisos enumerados como peligrosos después de 6.0 deben aplicarse dinámicamente en el código. Hay 4 niveles de permiso en Android, a saber, normal, peligroso, firma y firmaOrSystem. De forma predeterminada, los desarrolladores de aplicaciones de terceros no pueden acceder a la funcionalidad protegida por permisos del sistema en los niveles de firma y firma o sistema. Por lo tanto, las aplicaciones que requieren funcionalidad protegida por estos niveles de permisos deben firmarse con el mismo certificado de plataforma. Sin embargo, sólo el creador del sistema operativo tiene acceso a la clave privada del certificado. Ahora entendemos por qué la App Store de Huawei en los teléfonos móviles Huawei puede instalar aplicaciones de forma silenciosa, mientras que la App Store solo puede ir a la página de instalación de la aplicación. Al mismo tiempo, Android Framework proporciona una clase PackageManagerService que es responsable de la administración de aplicaciones en Android. Una función importante de este servicio es la administración de permisos y es responsable de verificar si la instalación y actualización de la aplicación cumple con el modelo de permisos.
4.Capa de aplicación
Los cuatro componentes principales y los permisos de la aplicación se declaran en AndroidManifest.
Las aplicaciones de Android se distribuyen en forma de archivos de paquetes de software de Android (.apk). Un paquete consta de un ejecutable Dalvik/ART, archivos de recursos, archivos de manifiesto y bibliotecas nativas, y está firmado por el desarrollador de la aplicación mediante un certificado autofirmado.
Cada aplicación consta de varios componentes de cuatro tipos: Actividad, Servicio, BoardcastReciver y Proveedor de contenido. Cada componente (excepto BoardcastReciver) debe declararse en AndroidManifest.xml. BoardcastReciver también se puede declarar dinámicamente en el código. a través de Intent, que es un método de comunicación especial basado en el marco Binder.
Las aplicaciones también pueden usar permisos personalizados para proteger el acceso a los componentes de la aplicación, similar a uno de los permisos del sistema. En otras palabras, si la aplicación 1 quiere proteger su acceso a A1, debe declarar una etiqueta de permiso P1. En este momento, si la aplicación 2 quiere acceder a C1, debe declarar el permiso P1 en AndroidManfest.xml.