Elementos de las apps
Android proporciona una plataforma de código abierto y un entorno de apps para dispositivos móviles. El sistema operativo principal se basa en el kernel de Linux. Las apps para Android se escriben con mayor frecuencia en el lenguaje de programación Java y se ejecutan en la máquina virtual de Android Runtime (ART). Sin embargo, las apps también se pueden escribir en código nativo. Las apps se instalan desde un solo archivo con la extensión APK.
Los principales componentes básicos de las apps para Android son los siguientes:
-
AndroidManifest.xml: El archivo AndroidManifest.xml es el archivo de control que le indica al sistema qué hacer con todos los componentes de nivel superior (en particular, las actividades, los servicios, los receptores de emisión y los proveedores de contenido que se describen a continuación) en una app. También especifica qué permisos son obligatorios.
-
Actividades: Por lo general, una actividad es el código de una sola tarea centrada en el usuario que usa la clase
Activity. Por lo general, una actividad incluye mostrarle una IU al usuario, pero no es obligatorio; algunas actividades nunca muestran IUs. Por lo general, una de las actividades de la app es el punto de entrada a la app. -
Servicios: Un servicio es un cuerpo de código que se ejecuta en segundo plano. Puede ejecutarse en su propio proceso o en el contexto del proceso de otra app. Otros componentes se "vinculan" a un servicio y lo invocan a través de llamadas de procedimiento remoto. Un ejemplo de un servicio es un reproductor multimedia: incluso cuando el usuario sale de la IU de selección de contenido multimedia, es probable que el usuario aún desee que la música siga reproduciéndose. Un servicio mantiene la música en reproducción incluso cuando se completa la IU.
-
Receptor de emisión: Un BroadcastReceiver es un objeto que se crea cuando el sistema operativo o otra app emite un mecanismo de IPC conocido como intent. Por ejemplo, una app puede registrar un receptor para el mensaje de batería baja y cambiar su comportamiento en función de esa información.
Modelo de permisos de Android: Accede a APIs protegidas
Todas las apps de Android se ejecutan en una Zona de pruebas de aplicaciones. De forma predeterminada, una app para Android solo puede acceder a un rango limitado de recursos del sistema. El sistema administra el acceso de las apps para Android a recursos que, si se usan de forma incorrecta o maliciosa, podrían afectar negativamente la experiencia del usuario, la red o los datos del dispositivo.
Estas restricciones se implementan de diferentes maneras. Algunas funciones están restringidas por una falta intencional de APIs a la funcionalidad sensible (por ejemplo, no hay una API de Android para manipular directamente la tarjeta SIM). En algunos casos, la separación de roles proporciona una medida de seguridad, como con el aislamiento de almacenamiento por app. En otros casos, las APIs sensibles están diseñadas para que las usen apps de confianza y se protegen a través de un mecanismo de seguridad conocido como permisos.
Estas APIs protegidas incluyen las siguientes:
- Funciones de la cámara
- Datos de ubicación (GPS)
- Funciones de Bluetooth
- Funciones de telefonía
- Funciones de SMS/MMS
- Conexiones de red o de datos
Solo se puede acceder a estos recursos a través del sistema operativo. Para usar las APIs protegidas en el dispositivo, una app debe definir las funciones que necesita en su manifiesto. Todas las versiones de Android 6.0 y posteriores usan un modelo de permisos de tiempo de ejecución. Si un usuario solicita una función de una app que requiere una API protegida, el sistema muestra un diálogo en el que se le pide al usuario que rechace o acepte el permiso.
Una vez otorgados, los permisos se aplican a la app, siempre que esta esté instalada. Para evitar confusiones, el sistema no vuelve a notificar al usuario los permisos otorgados a la app, y las apps que se incluyen en el sistema operativo principal o que un OEM incluye en un paquete no solicitan permisos al usuario. Los permisos se quitan si se desinstala una app, por lo que una reinstalación posterior vuelve a mostrar los permisos.
En la configuración del dispositivo, los usuarios pueden ver los permisos de las apps que instalaron anteriormente. Los usuarios también pueden desactivar algunas funciones de forma global cuando lo deseen, como el GPS, la radio o la conexión Wi-Fi.
En caso de que una app intente usar una función protegida que no se declaró en el manifiesto de la app, el error de permiso suele generar una excepción de seguridad que se devuelve a la app. Las verificaciones de permisos de API protegidos se aplican en el nivel más bajo posible para evitar la elusión. En la Figura 2, se muestra un ejemplo de los mensajes para el usuario cuando se instala una app mientras se solicita acceso a APIs protegidas.
Los permisos predeterminados del sistema se describen en https://developer.android.com/reference/android/Manifest.permission.html. Las apps pueden declarar sus propios permisos para que los usen otras apps. Estos permisos no se indican en la ubicación anterior.
Cuando se define un permiso, un atributo protectionLevel le indica al sistema cómo se debe informar al usuario de las apps que requieren el permiso o quién puede tener un permiso. En https://developer.android.com/guide/topics/security/security.html, se describen los detalles para crear y usar permisos específicos de la app.
Hay algunas funciones del dispositivo, como la capacidad de enviar intents de transmisión de SMS, que no están disponibles para apps de terceros, pero que pueden usar las apps preinstaladas por el OEM. Estos permisos usan el permiso signatureOrSystem.
Cómo entienden los usuarios las apps de terceros
Android se esfuerza por aclararles a los usuarios cuándo interactúan con apps de terceros y por informarles sobre las capacidades que tienen esas apps. Antes de instalar cualquier app, se le muestra al usuario un mensaje claro sobre los diferentes permisos que solicita la app. Después de la instalación, no se le vuelve a solicitar al usuario que confirme ningún permiso.
Existen muchos motivos para mostrar los permisos inmediatamente antes del tiempo de instalación. Esto ocurre cuando el usuario revisa de forma activa la información sobre la app, el desarrollador y la funcionalidad para determinar si coincide con sus necesidades y expectativas. También es importante que aún no hayan establecido un compromiso mental o financiero con la app y que puedan compararla fácilmente con otras apps alternativas.
Algunas otras plataformas usan un enfoque diferente para la notificación al usuario y solicitan permiso al comienzo de cada sesión o mientras se usan las apps. La visión de Android es que los usuarios cambien sin problemas entre apps a voluntad. Proporcionar confirmaciones cada vez ralentizaría al usuario y evitaría que Android ofrezca una experiencia del usuario excelente. Si el usuario revisa los permisos durante la instalación, tiene la opción de no instalar la app si no se siente cómodo.
Además, muchos estudios de interfaz de usuario demostraron que si se le solicita demasiado al usuario, este comienza a decir “OK” a cualquier diálogo que se le muestre. Uno de los objetivos de seguridad de Android es transmitir información de seguridad importante de manera eficaz al usuario, lo que no se puede hacer con diálogos que el usuario aprenderá a ignorar. Cuando se presenta la información importante una vez y solo cuando es importante, es más probable que el usuario piense en lo que está aceptando.
Algunas plataformas deciden no mostrar ninguna información sobre la funcionalidad de la app. Ese enfoque evita que los usuarios comprendan y discutan fácilmente las capacidades de la app. Si bien no es posible que todos los usuarios tomen decisiones siempre fundamentadas, el modelo de permisos de Android permite que una amplia variedad de usuarios acceda fácilmente a la información sobre las apps. Por ejemplo, las solicitudes de permisos inesperadas pueden hacer que los usuarios más sofisticados hagan preguntas fundamentales sobre la funcionalidad de la app y compartan sus inquietudes en lugares como Google Play, donde todos los usuarios pueden verlas.
| Permisos en la instalación de la app: Google Traductor | Permisos de una app instalada: Gmail |
|---|---|
 |
 |
Figura 1: Visualización de permisos de apps
Comunicación entre procesos
Los procesos pueden comunicarse con cualquiera de los mecanismos tradicionales de tipo UNIX. Entre los ejemplos, se incluyen el sistema de archivos, los sockets locales o los indicadores. Sin embargo, se siguen aplicando los permisos de Linux.
Android también proporciona nuevos mecanismos de IPC:
-
Binder: Es un mecanismo ligero de llamada de procedimiento remoto basado en capacidades, diseñado para un alto rendimiento cuando se realizan llamadas en el proceso y entre procesos. Binder se implementa con un controlador de Linux personalizado. Consulta https://developer.android.com/reference/android/os/Binder.html.
-
Servicios: Los servicios (que se analizaron anteriormente) pueden proporcionar interfaces a las que se puede acceder directamente con Binder.
-
Intents: Un intent es un objeto de mensaje simple que representa una "intención" de hacer algo. Por ejemplo, si tu app quiere mostrar una página web, expresa su "intent" para ver la URL creando una instancia de intent y pasándola al sistema. El sistema localiza otro fragmento de código (en este caso, el navegador) que sabe cómo controlar ese Intent y lo ejecuta. Los intents también se pueden usar para transmitir eventos interesantes (como una notificación) en todo el sistema. Consulta https://developer.android.com/reference/android/content/Intent.html.
-
ContentProviders: Un ContentProvider es un almacén de datos que proporciona acceso a los datos del dispositivo. El ejemplo clásico es el ContentProvider que se usa para acceder a la lista de contactos del usuario. Una app puede acceder a los datos que otras apps expusieron a través de un ContentProvider, y también puede definir sus propios ContentProviders para exponer sus propios datos. Consulta https://developer.android.com/reference/android/content/ContentProvider.html.
Si bien es posible implementar la IPC con otros mecanismos, como sockets de red o archivos que admiten escritura pública, estos son los frameworks de IPC de Android recomendados. Se alentará a los desarrolladores de Android a usar las prácticas recomendadas para proteger los datos de los usuarios y evitar la introducción de vulnerabilidades de seguridad.
APIs sensibles al costo
Una API sensible al costo es cualquier función que pueda generar un costo para el usuario o la red. La plataforma de Android colocó las APIs sensibles al costo en la lista de APIs protegidas que controla el SO. El usuario deberá otorgar permiso explícito a las apps de terceros que soliciten el uso de APIs sensibles al costo. Entre estas APIs, se incluyen las siguientes:
- Telefonía
- SMS y MMS
- Red/datos
- Facturación integrada en la aplicación
- Acceso NFC
Android 4.2 agrega más control sobre el uso de SMS. Android proporcionará una notificación si una app intenta enviar SMS a un código corto que utiliza servicios premium que pueden generar cargos adicionales. El usuario puede elegir si desea permitir que la app envíe el mensaje o bloquearla.
Acceso a la tarjeta SIM
El acceso de bajo nivel a la tarjeta SIM no está disponible para las apps de terceros. El SO controla todas las comunicaciones con la tarjeta SIM, incluido el acceso a la información personal (contactos) en la memoria de la tarjeta SIM. Las apps tampoco pueden acceder a los comandos AT, ya que la capa de interfaz de radio (RIL) los administra de forma exclusiva. El RIL no proporciona APIs de alto nivel para estos comandos.
Información personal
Android colocó las APIs que proporcionan acceso a los datos del usuario en el conjunto de APIs protegidas. Con el uso normal, los dispositivos Android también acumularán datos del usuario dentro de las apps de terceros que los usuarios instalen. Las apps que elijan compartir esta información pueden usar las verificaciones de permisos del SO Android para proteger los datos de las apps de terceros.
Figura 2: El acceso a los datos sensibles del usuario solo está disponible a través de APIs protegidas
Los proveedores de contenido del sistema que puedan contener información personal o de identificación personal, como contactos y calendarios, se crearon con permisos claramente identificados. Este nivel de detalle le proporciona al usuario una indicación clara de los tipos de información que se pueden proporcionar a la app. Durante la instalación, una app de terceros puede solicitar permiso para acceder a estos recursos. Si se otorga el permiso, la app se puede instalar y tendrá acceso a los datos solicitados en cualquier momento cuando se instale.
De forma predeterminada, las apps que recopilan información personal tendrán esos datos restringidos solo a la app específica. Si una app decide poner los datos a disposición de otras apps a través del IPC, la app que otorga acceso puede aplicar permisos al mecanismo de IPC que aplica el sistema operativo.
Dispositivos de entrada de datos sensibles
Los dispositivos Android suelen proporcionar dispositivos de entrada de datos sensibles que permiten que las apps interactúen con el entorno circundante, como la cámara, el micrófono o el GPS. Para que una app de terceros acceda a estos dispositivos, el usuario primero debe otorgarle acceso de forma explícita mediante los permisos del SO Android. Durante la instalación, el instalador le solicitará al usuario permiso al sensor por nombre.
Si una app quiere conocer la ubicación del usuario, requiere un permiso para acceder a ella. Durante la instalación, el instalador le preguntará al usuario si la app puede acceder a su ubicación. En cualquier momento, si el usuario no quiere que ninguna app acceda a su ubicación, puede ejecutar la app de Configuración, ir a "Ubicación y seguridad" y desmarcar las opciones "Usar redes inalámbricas" y "Habilitar satélites GPS". Esto inhabilitará los servicios basados en la ubicación para todas las apps del dispositivo del usuario.
Device metadata
Android también se esfuerza por restringir el acceso a los datos que no son intrínsecamente sensibles, pero que pueden revelar indirectamente características sobre el usuario, sus preferencias y la forma en que usa un dispositivo.
De forma predeterminada, las apps no tienen acceso a los registros del sistema operativo, al historial del navegador, al número de teléfono ni a la información de identificación de hardware o red. Si una app solicita acceso a esta información durante la instalación, el instalador le preguntará al usuario si la app puede acceder a la información. Si el usuario no otorga acceso, la app no se instalará.
Autoridades certificadoras
Android incluye un conjunto de autoridades certificadoras del sistema instaladas, que son confiables en todo el sistema. Antes de Android 7.0, los fabricantes de dispositivos podían modificar el conjunto de AC que se enviaban en sus dispositivos. Sin embargo, los dispositivos que ejecutan 7.0 y versiones posteriores tendrán un conjunto uniforme de AC del sistema, ya que ya no se permite que los fabricantes de dispositivos realicen modificaciones.
Para agregarse como una AC pública nueva al conjunto de AC de Android, la AC debe completar el Proceso de inclusión de AC de Mozilla y, luego, enviar una solicitud de función a Android ( https://code.google.com/p/android/issues/entry) para que se agregue la AC al conjunto de AC de Android estándar en el Proyecto de código abierto de Android (AOSP).
Aún existen AC específicas del dispositivo que no deben incluirse en el conjunto principal de AC de AOSP, como las AC privadas de los operadores que pueden ser necesarias para acceder de forma segura a los componentes de la infraestructura del operador, como las puertas de enlace de SMS/MMS. Se recomienda a los fabricantes de dispositivos que incluyan las AC privadas solo en los componentes o las apps que deban confiar en ellas. Para obtener más detalles, consulta Configuración de seguridad de red.
Firma de apps
La firma de código permite a los desarrolladores identificar al autor de la app y actualizarla sin crear interfaces ni permisos complicados. El desarrollador debe firmar cada app que se ejecuta en la plataforma de Android. Google Play o el instalador de paquetes del dispositivo Android rechazan las apps que intentan instalarse sin firmar.
En Google Play, la firma de apps une la confianza que Google tiene en el desarrollador y la que el desarrollador tiene en su app. Los desarrolladores saben que su app se proporciona sin modificaciones al dispositivo Android y que pueden ser responsables del comportamiento de su app.
En Android, la firma de apps es el primer paso para colocar una app en su zona de pruebas. El certificado de la app firmado define qué ID de usuario está asociado con qué app. Las diferentes apps se ejecutan con diferentes IDs de usuario. La firma de apps garantiza que una app no pueda acceder a ninguna otra app, excepto a través de un IPC bien definido.
Cuando se instala una app (archivo APK) en un dispositivo Android, el Administrador de paquetes verifica que el APK se haya firmado correctamente con el certificado incluido en él. Si el certificado (o, más precisamente, la clave pública en el certificado) coincide con la clave que se usa para firmar cualquier otro APK en el dispositivo, el APK nuevo tiene la opción de especificar en el manifiesto que compartirá un UID con los otros APK firmados de manera similar.
Las apps pueden estar firmadas por un tercero (OEM, operador o mercado alternativo) o autofirmadas. Android proporciona la firma de código con certificados autofirmados que los desarrolladores pueden generar sin asistencia ni permiso externos. Las apps no tienen que estar firmadas por una autoridad central. Actualmente, Android no realiza la verificación de la AC para los certificados de apps.
Las apps también pueden declarar permisos de seguridad en el nivel de protección de la firma, lo que restringe el acceso solo a las apps firmadas con la misma clave y, al mismo tiempo, mantiene UIDs y zonas de pruebas de aplicaciones distintas. Se permite una relación más estrecha con una zona de pruebas de aplicaciones compartida a través de la función de UID compartido, en la que dos o más apps firmadas con la misma clave de desarrollador pueden declarar un UID compartido en su manifiesto.
Verificación de apps
Android 4.2 y versiones posteriores admiten la verificación de apps. Los usuarios pueden habilitar "Verificar aplicaciones" y hacer que un verificador de aplicaciones evalúe las apps antes de la instalación. La verificación de aplicaciones puede alertar al usuario si intenta instalar una app que puede ser dañina. Si una app es particularmente mala, puede bloquear su instalación.
Administración de derechos digitales
La plataforma de Android proporciona un framework extensible de administración de derechos digitales (DRM) que permite a las apps administrar contenido protegido por derechos según las restricciones de licencia asociadas con el contenido. El framework de DRM admite muchos esquemas de DRM. El fabricante del dispositivo es quien determina qué esquemas de DRM admite un dispositivo.
El marco de trabajo de DRM de Android se implementa en dos capas arquitectónicas (consulta la siguiente imagen):
-
Una API del framework de DRM, que se expone a las apps a través del framework de apps de Android y se ejecuta a través de la VM de ART para apps estándar.
-
Un administrador de DRM de código nativo, que implementa el framework de DRM y expone una interfaz para que los complementos de DRM (agentes) administren la administración de derechos y la desencriptación para varios esquemas de DRM
Figura 3: Arquitectura de la DRM en la plataforma de Android