PRIVACIDAD: Android VS. *NIX:
PROTECCIÓN:
Estar protegido tiene un significado muy amplio, que varía según las personas y las situaciones. Comparando Android con los sistemas *NIX, hay que reconocer que el primero ofrece más aislamiento entre aplicaciones y un control más fino de los permisos. Ejemplos rápidos:
- En el PC, el usuario confía en todos los procesos / aplicaciones que se ejecutan bajo el mismo UID (normalmente un usuario humano) ( 1 ) . En Android no es el caso; cada aplicación es un usuario diferente para tener posiblemente una influencia mínima en otras aplicaciones.
- Un usuario de PC puede conseguir fácilmente superusuario / derechos de administrador, un usuario de Android no puede ( 2 ) .
La demanda y la razón son obvias:
- La privacidad importa más porque un teléfono es un
24/7 inevitablemente asistente, así como un perfecto espía equipado con todas las herramientas de hardware necesarias.
- Y la razón es que es fácil implementar un entorno más restrictivo en un dispositivo menos personalizable.
El DAC tradicional de *NIX se remonta a los primeros días de la informática personal, cuando el aislamiento se centró sólo entre usuarios (UID's/GID's), no entre procesos / aplicaciones. Debido a que no existía un código cerrado aplicaciones de pago en las tiendas de desconocido desarrolladores; no hay muchos datos personales que proteger procesos maliciosos ; ningún usuario perfilando , dirigido a anuncio , rastreadores, analíticas, ransomware y así sucesivamente.
MECANISMOS DE SEGURIDAD:
*NIX DAC se consideró insuficiente, especialmente con la revolución de Internet, por lo que los privilegios de superusuario se dividieron en capacidades y se introdujeron nuevos mecanismos de "sandboxing" a nivel del kernel, incluyendo MAC y espacios de nombres . Android hace uso de todos ellos más o menos, controlan a qué recursos puede acceder un proceso en el dispositivo. También, cgroups controlar la cantidad de recursos que puede utilizar un proceso. Pero incluso entonces, estos mecanismos de seguridad no eran suficientes para bloquear minuciosamente las aplicaciones Por lo tanto, una serie de controles se manejan dentro del propio marco de Android (en el espacio de usuario). Los controles de Android servidor_sistema tiene más servicios que se ejecutan en su interior que los servicios nativos. Cuando digo "los mecanismos no eran suficientes" La preocupación no es sólo diseñar un ecosistema para proteger privacidad / seguridad del usuario sino también para proteger el modelo de negocio de Google y de los desarrolladores de aplicaciones.
PC VS. Android:
También hay que tener en cuenta que no hay normalización en el mundo de Android (más bien en el de los empotrados) a diferencia de los PC. Android utiliza un kernel de Linux modificado, que no maneja completamente el hardware en núcleo espacio, sino que se basa en un número de espacio de usuario fuente cerrada procesos de los proveedores de SoC / OEM ( 3 ) que interactúan con otros procesos y controladores de hardware mediante el uso de herramientas específicas de Android mecanismo binder / HAL . Así que *NIX DAC, que está fuertemente basado en todo es un archivo filosofía, no parece funcionar muy lejos. Un dispositivo de hardware no es más que un archivo en /dev al que se puede acceder añadiendo el proceso de la app a algún grupo complementario, hay capas de APIs y CIPs implicados (Java y nativo).
Sin embargo, Android se aprovecha de los robustos marcos del kernel de Linux, como el DAC. Aplicaciones conexión a internet se controla añadiéndolos a un grupo suplementario especial 3003 . Ver: ¿Cómo funciona el mapeo de permisos de Android con UIDs/GIDs?
QUÉ SE DEBE PROTEGER EN ANDROID:
En cuanto al control granular del usuario sobre la seguridad y la privacidad en el dispositivo Android, algunas cosas que pueden preocupar son quién puede:
- Acceder a los datos personales (fotos, documentos, vídeos, copias de seguridad, etc.)
- Obtener información de las cuentas (añadida por aplicaciones como Google)
- Obtenga acceso de lectura/escritura a los datos de los proveedores de contenido como:
- Contactos
- Registro de llamadas
- Mensajes
- Leer los identificadores del usuario/dispositivo (dirección MAC, IMEI, Android ID, etc.)
- Leer las estadísticas de uso
- Buscar aplicaciones instaladas
- Acceder a la cámara, grabar audio/vídeo
- Hacer llamadas, enviar mensajes
- Conseguir conexión a Internet
- Obtener la ubicación del dispositivo
- Se ejecuta en segundo plano (por ejemplo, aplicaciones de vigilancia o seguimiento)
Y así sucesivamente.
PERMISOS DE APLICACIONES Y SANDBOXING:
Android divide su APIs protegidas en diferentes Niveles de protección . El acceso de las aplicaciones a la mayoría de los recursos mencionados está controlado por permisos manifiestos o el usuario tiene no hay control sobre ellos.
- Por ejemplo, no se puede restringir el acceso de una aplicación a Internet sin utilizar un firewall de terceros. Cada aplicación que solicita
INTERNET en el momento de la instalación, no se puede eliminar su grupo complementario AID_INET (3003) .
- Asimismo,
READ_CONTACTS y GET_ACCOUNTS Los permisos pertenecen al mismo grupo y se controlan con el mismo interruptor de palanca en la GUI.
- Y no puedes negar que una aplicación se ejecute en segundo plano a menos que utilices el gestor de permisos ocultos de Android: AppOps .
- Y eso no es el final. Si quieres un control más fino sobre los permisos, por ejemplo, revocar la capacidad de una aplicación para getInstalledApplications se necesita algún modificador de marco pesado como Xposed y XPrivacy .
A cada aplicación se le asigna un UID/GID único en el momento de la instalación y se ejecuta dentro de su propia postura de Máquina virtual , bifurcado por zygote . DAC aplicado a los sistemas de archivos, las aplicaciones están obligadas a acceder sólo a sus propios directorios, especialmente en el almacenamiento interno ( /data/user/<UserId>/<pkg_name> ), almacenamiento externo privado/público ( /data/media/<UserId> ) y procfs ( /proc/self/ etc.).
La caja de arena DAC también se complementa con MAC, por ejemplo Política SELinux no permite que las aplicaciones lean /proc/stat y rootfs (/) (pero permitirles leer el directorio de datos de otras aplicaciones ( 4 ) ;). Por otro lado /data/misc/profiles/cur/<UserId>/<pkg_name> está permitido por DAC pero restringido por SELinux.
AISLAMIENTO DE MÚLTIPLES USUARIOS:
Una aplicación XYZ en la cuenta de usuario principal con UID/GID 10500 puede acceder a sus datos privados/configuración/bases de datos en /data/user/0/<com.xyz> pero no en la cuenta de usuario secundaria porque /data/user/xx/<com.xyz> tiene UID/GID propietario xx10500 donde xx es ID de usuario . Cómo controla DAC el acceso a /sdcard (almacenamiento externo) se explica en ¿Qué es el UID "u#_everybody"?
Sandboxing básico el aislamiento existe entre las aplicaciones tanto si son del mismo como de diferentes usuarios. Pero un notable aislamiento adicional entre aplicaciones de diferentes cuentas/perfiles de usuario es el almacenamiento compartido independiente (es decir /sdcard ), lo cual es una ventaja, obviamente, si no confías en la aplicación. Es porque una aplicación tiene acceso o bien sólo a sus directorios privados, o bien a todo el almacenamiento externo. Este problema de archivos públicos demasiado abiertos se controla a través del cambio de privacidad de Android Q: Almacenamiento de alcance .
Este aislamiento entre aplicaciones de diferentes cuentas/perfiles de usuario también existe en Marco de trabajo de Java nivel. Por ejemplo, en nuestro ejemplo anterior, getInstalledApplications " devuelve una lista de todos los paquetes de aplicaciones que están instalados para el usuario actual " sólo. Así que una aplicación no podrá averiguar qué aplicaciones tienes instaladas en otra cuenta/perfil de usuario.
Dado que los datos de las aplicaciones instaladas están aislados, la proveedores de contenidos (que también son aplicaciones del sistema) también están aisladas. Por lo tanto, el contacts , call logs , calendars , messages , media (lista de archivos en el almacenamiento externo), etc. no se comparten entre los usuarios.
Otras cosas que están aisladas entre los usuarios (no necesariamente impuestas por DAC/MAC):
- Ajustes del usuario/de la aplicación que están sujetos a las autentificaciones FDE, FBE y de la contraseña (
/data/user_de/<UserId>/<pkg_name> , /data/misc/keystore/user_<UserId> , /data/misc/gatekeeper/<UserId> etc.) ( 5 , 6 )
- Estadísticas de uso de las aplicaciones (
/data/system/usagestats/<UserId> )
- Cuentas y configuraciones de todo el sistema, no todas (
/data/system/users/<UserId> )
- Certificados de CA personalizados (
/data/misc/user/<UserId> )
- Datos de los perfiles ART (
/data/misc/profiles/cur/<UserId> )
CONCLUSIÓN:
Así que en el mundo de Android a diferencia de los PC's, todo no se rige por uid's / gid's En gran parte, estamos a merced del marco central de Android. Pero el aislamiento entre múltiples usuarios existe, sin embargo depende de lo que quieras proteger de las aplicaciones.
REFERENCIA:
