MOTIF 1 :
En dehors de la tradition Contrôle d'accès discrétionnaire (Android met en œuvre plusieurs autres mécanismes de contrôle d'accès du noyau Linux afin de se rendre plus sûr, tels que Le filtre Seccomp a été mis en place dans Oreo .
MOTIF 2 :
Alors que le DAC est allowed by-default SELinux (un Contrôle d'accès obligatoire ) fonctionne en denied by-default mode. Toute tentative d'accès qui n'est pas explicitement autorisée par une règle de politique SE sera refusée. De la même manière, l'accès à /proc fs a été renforcé dans Android O qui ne laissera pas un processus/utilisateur non privilégié lire - par exemple -. /proc/stat y /proc/filesystem . La même chose vous empêche de lire /proc/1 lorsque vous vous exécutez en tant qu'utilisateur non-Root à partir de votre application.
Si SELinux sur votre appareil n'est pas Enforcing vous devez pouvoir lire /proc/1 mais il existe d'autres restrictions de sécurité qui, contrairement à DAC et MAC, sont spécifiques à /proc pseudo-système de fichiers.
MOTIF 3 :
Montures Android par défaut /proc avec hidepid=2,gid=3009 ce qui signifie qu'un utilisateur non privilégié ne pourra voir que ses propres processus (s'exécutant avec le même UID). ( ref ) . Votre application ne pourra donc pas voir le répertoire /proc/1 . La seule exception concerne les processus qui sont membres du groupe AID_READPROC (GID 3009).
MOTIF 4 :
Mais si vous (re)montez /proc sans option hidepid vous ne pourrez pas lire /proc/1/maps car le noyau Linux n'autorise que les processus ayant la capacité SYS_PTRACE pour lire les détails de l'actuelle régions de mémoire mappées .
Voici un exemple de processus non racine fonctionnant sous Android incidentd qui fonctionne avec CAP_SYS_PTRACE ainsi qu'un membre du groupe READPROC . Il convient également de définir la règle de politique SE suivante pour autoriser l'accès :
allow incidentd init : file { read getattr open }
LOGGING :
En ce qui concerne l'enregistrement des refus d'autorisation, logd (le service à partir duquel logcat reads) est un démon de journalisation spécifique à Android qui enregistre nécessairement les événements provenant du cadre natif et du cadre Java d'Android (tels que autorisation manifeste ), mais inclut également les événements du noyau (que nous pouvons également voir à l'aide de l'outil en ligne de commande natif dmesg ). Les refus de SELinux sont également consignés dans le journal du noyau :
$ ls /proc/1
ls: cannot access '/proc/1': Permission denied
# dmesg | grep avc
[37914.650314] type=1400 audit(1548757064.171:33323): avc: denied { getattr } for pid=28576 comm="ls" path="/proc/1" dev="proc" ino=803674 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:r:init:s0 tclass=dir permissive=0
# logcat | grep avc
01-29 14:17:44.171 28576 28576 W ls : type=1400 audit(0.0:33323): avc: denied { getattr } for path="/proc/1" dev="proc" ino=803674 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:r:init:s0 tclass=dir permissive=0
Cependant, le noyau Linux peut ou non enregistrer tous ses refus de permission internes en fonction de plusieurs facteurs de construction et d'exécution. configurations y compris printk loglevel , DYNAMIC_DEBUG et/ou d'autres dont je ne suis pas sûr. Il se peut donc que ces messages n'apparaissent pas dans les journaux.
Si vous souhaitez obtenir les journaux relatifs aux événements de sécurité, vous pouvez utiliser les fonctions suivantes du noyau Linux Auditing System . Pour cela, vous devez utiliser auditctl outil de définition des règles ( Racine nécessaire ), et vous obtiendrez des détails sur les refus dans les journaux par l'intermédiaire de dmesg o logcat . Pour plus de détails sur la définition des règles, voir cette réponse .
PS :
Une autre raison pour laquelle il n'est pas possible d'accéder à un certain PID dans procfs est la suivante PID namespace qui n'est pas pertinent sur Android pour l'instant, mais qui est très courant pour les mécanismes d'isolation tels que conteneurs . Dans un nouvel espace de noms PID, tout processus de l'espace de noms parent n'est pas visible et un processus peut avoir le même PID (y compris PID 1 ; init) que celui d'un autre processus dans un autre espace de noms PID.
