Est-ce que les utilisateurs multiples sont protégés les uns des autres différemment des applications ?

PRIVACY : Android VS. *NIX :

LA PROTECTION :

Être protégé a une signification très vaste, variant selon les personnes et les situations. Si l'on compare Android aux systèmes *NIX, il est vrai que le premier offre une plus grande isolation entre les applications et un contrôle plus fin des permissions. Exemples rapides :

• Sur un PC, l'utilisateur fait confiance à tous les processus/applications fonctionnant sous le même UID (généralement un utilisateur humain). ( 1 ) . Sur Android, ce n'est pas le cas ; chaque application est un utilisateur différent pour avoir une influence minimale sur les autres applications.
• Un utilisateur de PC peut facilement obtenir superutilisateur / droits d'administrateur, un utilisateur Android ne peut pas ( 2 ) .

La demande et la raison sont évidentes :

• La vie privée compte davantage parce qu'un téléphone est un 24/7 inévitable assistant ainsi qu'un parfait espionner équipé de tous les outils matériels nécessaires.
• Y la raison est qu'il est facile de mettre en place un environnement plus restrictif sur un appareil moins personnalisable.

Le DAC traditionnel de *NIX remonte aux premiers jours de l'informatique personnelle, lorsque le isolement était uniquement axé sur les utilisateurs (UID/GID), et non sur les processus/applications. Parce qu'il n'y avait pas de logiciel fermé Applications payantes dans les magasins à partir de inconnu développeurs ; peu de données personnelles à protéger de processus malveillants ; aucun utilisateur profilage ciblé publicité les trackers, les analyses, ransomware et ainsi de suite.

LES MÉCANISMES DE SÉCURITÉ :

*NIX DAC s'est avéré insuffisant, en particulier avec la révolution de l'Internet, et les privilèges des superutilisateurs ont donc été divisés en deux catégories capacités et de nouveaux mécanismes de sandboxing ont été introduits au niveau du noyau, notamment MAC y espaces de noms . Android les utilise tous plus ou moins, ils contrôlent les ressources auxquelles un processus peut accéder sur le périphérique. Aussi, cgroups contrôler la quantité de ressources qu'un processus peut utiliser. Mais même à cette époque, ces mécanismes de sécurité n'étaient pas suffisants pour verrouiller minutieusement les applications Un certain nombre de contrôles sont donc gérés dans le propre cadre d'Android (dans l'espace utilisateur). Le système Android système_serveur a plus de services fonctionnant en son sein que les services natifs. Quand je dis "les mécanismes n'étaient pas suffisants" La préoccupation de l'UE n'est pas seulement de concevoir un écosystème pour protéger l'environnement. confidentialité / sécurité de l'utilisateur mais aussi pour protéger le modèle économique de Google et celui des développeurs d'applications.

PC VS. Android :

Il convient également de noter qu'il n'y a pas normalisation dans le monde Android (plutôt dans le monde embarqué) contrairement aux PC. Android utilise un noyau Linux modifié, qui ne gère pas complètement le matériel dans le monde de l'embarqué. Noyau s'appuie plutôt sur un certain nombre d'éléments de l'espace utilisateur. source fermée les processus des fournisseurs de SoC / OEM ( 3 ) qui interagissent avec d'autres processus et des pilotes matériels en utilisant des outils spécifiques à Android. mécanisme de reliure / HAL . Donc *NIX DAC, qui est fortement basé sur tout est un fichier philosophie, ne semble pas fonctionner très loin. Un dispositif matériel n'est pas plus qu'un simple fichier en /dev auxquels on peut accéder en ajoutant le processus d'application à un groupe supplémentaire, il existe des couches de APIs y IPCs impliqués (Java et natif).

Toutefois, Android tire parti des cadres robustes du noyau Linux, comme le DAC. Apps' connectivité internet est contrôlé en les ajoutant à un groupe supplémentaire spécial 3003 . Voir : Comment fonctionne le mappage des permissions d'Android avec les UID/GID ?

CE QUI DOIT ÊTRE PROTÉGÉ SUR Android :

En ce qui concerne le contrôle granulaire de l'utilisateur sur la sécurité et la vie privée sur un appareil Android, on peut s'inquiéter de savoir qui peut le faire :

• Accéder aux données personnelles (photos, documents, vidéos, sauvegardes, etc.)
• Obtenir des informations sur les comptes (ajoutées par des applications, dont Google)
• Obtenez un accès en lecture/écriture aux données des fournisseurs de contenu comme :
  • Contacts
  • Journal des appels
  • Messages
• Lire les identifiants de l'utilisateur / de l'appareil (adresse MAC, IMEI, Android ID, etc.)
• Lire les statistiques d'utilisation
• Trouver les applications installées
• Accès à la caméra, enregistrement audio/vidéo
• Passer des appels, envoyer des messages
• Obtenir une connectivité internet
• Obtenir l'emplacement du dispositif
• fonctionner en arrière-plan (par exemple, les applications de surveillance ou de suivi)

Et ainsi de suite.

LES AUTORISATIONS D'APPLICATIONS ET LE SANDBOXING :

Android divise ses APIs protégées dans différents Niveaux de protection . L'accès des applications à la plupart des ressources susmentionnées est contrôlé par les services suivants autorisations du manifeste ou l'utilisateur a aucun contrôle sur eux.

• Par exemple, vous ne pouvez pas restreindre l'accès d'une application à Internet sans utiliser un pare-feu tiers. Toute application qui demande un accès à INTERNET est accordée au moment de l'installation, vous ne pouvez pas supprimer son groupe supplémentaire. AID_INET (3003) .
• De même, READ_CONTACTS y GET_ACCOUNTS appartiennent au même groupe et sont contrôlées par le même interrupteur à bascule sur l'interface graphique.
• Et vous ne pouvez pas empêcher une application de fonctionner en arrière-plan, à moins d'utiliser le gestionnaire de permissions cachées d'Android : AppOps .
• Et ce n'est pas la fin. Si vous souhaitez un contrôle plus fin des permissions, par exemple en révoquant la capacité d'une application à getInstalledApplications vous avez besoin d'un modificateur de cadre lourd comme Xposed y XPrivacy .

Chaque application se voit attribuer un UID/GID unique au moment de l'installation et s'exécute dans son propre espace de travail. Machine virtuelle bifurqué par zygote . DAC appliqué aux systèmes de fichiers, les applications ne peuvent accéder qu'à leurs propres répertoires, en particulier sur le stockage interne ( /data/user/<UserId>/<pkg_name> ), le stockage externe privé/public ( /data/media/<UserId> ) et procfs ( /proc/self/ etc.).

Le sandboxing du DAC est également complété par le MAC, par exemple. Politique SELinux ne permet pas aux applications de lire /proc/stat y rootfs (/) (mais leur permettre de lire le répertoire de données d'autres applications). ( 4 ) ;). D'un autre côté /data/misc/profiles/cur/<UserId>/<pkg_name> est autorisé par le DAC mais restreint par SELinux.

L'ISOLEMENT DE PLUSIEURS UTILISATEURS :

Une application XYZ dans le compte de l'utilisateur principal avec UID/GID 10500 peut accéder à ses données/réglages/bases de données privés en /data/user/0/<com.xyz> mais pas dans le compte d'utilisateur secondaire car /data/user/xx/<com.xyz> a un UID/GID propriétaire xx10500 donde xx est ID utilisateur . Comment le CED contrôle l'accès à /sdcard (stockage externe) est expliqué dans Qu'est-ce que l'UID "u#_everybody" ?

Sandboxing de base il existe une isolation entre les applications qu'ils proviennent du même utilisateur ou d'utilisateurs différents. Mais une isolation supplémentaire notable entre les applications de différents comptes/profils d'utilisateurs est la stockage partagé séparé (c'est-à-dire /sdcard ), ce qui est évidemment un avantage si vous ne faites pas confiance à l'application. C'est parce qu'une application a accès soit uniquement à ses répertoires privés, soit à l'ensemble du stockage externe. Ce problème de des dossiers publics trop ouverts est contrôlé par le changement de confidentialité d'Android Q : Stockage de la portée .

Cette isolation entre les applications de différents comptes/profils d'utilisateurs existe également au niveau de l'UE. Cadre Java niveau. Par exemple, dans notre exemple ci-dessus, getInstalledApplications " renvoie une liste de tous les paquets d'applications qui sont installés pour l'utilisateur. utilisateur actuel " seulement. Une application ne pourra donc pas savoir quelles applications vous avez installées sur un autre compte utilisateur/profil.

Puisque les données des applications installées sont isolées, le système Android standard fournisseurs de contenu (qui sont également des applications système) sont également isolées. Ainsi, le contacts , call logs , calendars , messages , media (liste de fichiers sur le stockage externe) etc. ne sont pas partagés entre les utilisateurs.

D'autres choses qui sont isolées entre les utilisateurs (pas nécessairement appliquées par le DAC/MAC) :

• Les paramètres de l'utilisateur/application qui sont soumis aux authentifications FDE, FBE et mot de passe ( /data/user_de/<UserId>/<pkg_name> , /data/misc/keystore/user_<UserId> , /data/misc/gatekeeper/<UserId> etc.) ( 5 , 6 )
• Statistiques d'utilisation des applications ( /data/system/usagestats/<UserId> )
• Comptes et paramètres du système, pas tous ( /data/system/users/<UserId> )
• Certificats d'AC personnalisés ( /data/misc/user/<UserId> )
• Données sur les profils ART ( /data/misc/profiles/cur/<UserId> )

CONCLUSION :

Ainsi, dans le monde Android, contrairement à celui des PC, tout n'est pas régi par uid's / gid's Si l'on se fie à ce qui précède, nous sommes en grande partie à la merci du cadre central d'Android. Mais l'isolation entre plusieurs utilisateurs existe, cependant cela dépend de ce que vous voulez protéger des applications.

RÉFÉRENCE :

• Utilisateurs multiples sur Android
• Linux contre Android