RAZÓN 1:
Además de los tradicionales Control de acceso discrecional (DAC), - que hace uso de *NIX propietario/grupo/modo de los procesos/archivos para permitir/denegar el acceso - Android implementa varios otros mecanismos de control de acceso del kernel de Linux para hacerse más seguro, tales como El filtro Seccomp se implementó en Oreo .
RAZÓN 2:
Mientras que el DAC es allowed by-default , SELinux (a Control de acceso obligatorio ) trabaja en denied by-default modo. Cualquier intento de acceso que no esté explícitamente permitido en una regla de Política SE será denegado. Utilizando lo mismo, el acceso a /proc fs se ha endurecido en Android O, que no dejará leer a un proceso/usuario sin privilegios -por ejemplo-. /proc/stat y /proc/filesystem . Lo mismo te restringe la lectura /proc/1 cuando se ejecuta como un usuario no root de su aplicación.
Si SELinux en su dispositivo no es Enforcing , deberías ser capaz de leer /proc/1 pero hay otras restricciones de seguridad que, a diferencia de DAC y MAC, son específicas de /proc pseudo sistema de archivos.
RAZÓN 3:
Montajes por defecto de Android /proc con hidepid=2,gid=3009 lo que significa que un usuario sin privilegios sólo podrá ver sus propios procesos (que se ejecutan con el mismo UID). Así que su aplicación no podrá ver el directorio /proc/1 . La única excepción son los procesos que son miembros del grupo AID_READPROC (GID 3009).
RAZÓN 4:
Pero aún así, si se (re)monta /proc sin opción hidepid no podrá leer /proc/1/maps porque el kernel de Linux sólo permite procesos con capacidad SYS_PTRACE para leer los detalles de actualmente regiones de memoria mapeadas .
Un ejemplo de proceso no root que funciona en Android es incidented que se ejecuta con CAP_SYS_PTRACE así como un miembro del grupo READPROC . También la regla de la Política SE como la siguiente debe ser definida para permitir el acceso:
allow incidentd init : file { read getattr open }
REGISTRO:
En cuanto al registro de las denegaciones de permisos, logcatd es un demonio de registro específico de Android que necesariamente registra eventos desde el marco nativo de Android y Java (como permiso manifiesto denials), pero opcionalmente incluye eventos del kernel (que también podemos ver usando la herramienta nativa de línea de comandos dmesg ). Las denegaciones de SELinux también se registran en el registro del kernel:
$ 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
Sin embargo, el kernel de Linux puede o no registrar todas sus denegaciones de permiso internas, dependiendo de múltiples construcciones y tiempos de ejecución configuraciones incluyendo printk loglevel , DYNAMIC_DEBUG y/u otros de los que no estoy seguro. Por lo tanto, estos mensajes pueden no aparecer en los registros.
PS:
Otra razón de no poder acceder a un determinado PID en procfs es PID namespace que no es relevante en Android hasta ahora, pero muy común para los mecanismos de aislamiento como contenedores . En un nuevo espacio de nombres PID, cualquier proceso del espacio de nombres padre no es visible y un proceso podría tener el mismo PID (incluyendo PID 1; init) que el de algún otro proceso en algún otro espacio de nombres PID.
