Depuis la première version de l'aperçu du développeur Android N, j'obtiens des erreurs "autorisation refusée" lorsque j'essaie de répertorier le répertoire racine ou d'autres répertoires système. Les autorisations sur ces répertoires ne semblent pas changer (pour autant que je sache).
Quel (s) changement (s) dans Android N a causé ces erreurs d'autorisation refusée?
Comment répliquer:
Dans ADB Shell, exécutez les commandes suivantes:
run-as com.debuggable.packagename
ls /
Cela donne des erreurs de refus d'autorisation sur Android N.
Pourquoi lister les répertoires système:
J'ai remarqué ce comportement sur Android N avec plusieurs gestionnaires de fichiers. Ils ne pouvaient plus répertorier le répertoire racine ou d'autres fichiers système. Cela limite également la sortie de l'exécution de ps
dans un Shell. Les modifications ont également provoqué l'arrêt de bibliothèque sur Android N.
Il y avait deux groupes de changements réduisant l'accès à/proc.
Le système de fichiers procfs est maintenant monté avec hidepid = 2, éliminant l'accès aux répertoires/proc/PID des autres utilisateurs. Ce changement a été implémenté dans CopperheadOS et a ensuite été adopté en amont sur cette base. Il existe un groupe pour faire des exceptions, mais il n'est pas exposé comme une autorisation. Il n'est utilisé que pour faire des exceptions pour certains processus du système de base. Cela pourrait être présenté comme une autorisation `` dangereuse '' et c'est ce que je pensais que Google finirait par faire, mais ils ont décidé que les utilisateurs n'en comprendraient pas les implications.
https://Android-review.googlesource.com/#/c/181345/
Les politiques SELinux sont également devenues beaucoup plus strictes. Pour les applications, il n'y a plus d'accès de base à/proc, bien que cela ne s'applique qu'aux fichiers autres que les répertoires/proc/PID. Il y a toujours accès à quelques fichiers dont les étiquettes ne relèvent pas de la politique générale de proc, mais la plupart du temps, ils ont disparu. Cela a été progressif et il existe de nombreux engagements pertinents. L'un des grands:
https://Android-review.googlesource.com/#/c/105337/
Non seulement cela supprime beaucoup d'informations évidentes, mais cela ferme également certains trous de sécurité plus flagrants impliquant des canaux latéraux permettant des choses comme l'enregistrement du clavier:
Les politiques SELinux sont également devenues beaucoup plus strictes en général au fil du temps. Vous pouvez voir le reste dans le référentiel platform/system/sepolicy . Notez qu'il était à platform/external/sepolicy pendant longtemps mais il a été récemment déplacé.
Cela a été fait pour raisons de sécurité et de confidentialité . Du rapport de bogue:
Dans le cas des systèmes de fichiers racine (/) et/sys, une liste de répertoires n'est pas possible.
La réponse officielle de Google:
Le comportement que vous décrivez fonctionne comme prévu. Android fournit des sandbox stricts dans lesquels les applications doivent s'exécuter. Ces sandbox protègent les données d'application d'autres applications, y compris les métadonnées d'application telles que l'état du processus.
/ sys et/proc sont bien connus pour la fuite d'informations de canal latéral sur les processus, informations qui peuvent être utilisées pour déduire l'état des processus. Par exemple, il est documenté depuis des années que l'accès/proc peut être utilisé pour surveiller le lancement d'applications, permettant des attaques de phishing.