Wenn Sie das Gerät nicht "root", als nein.
Die Details sind wie folgt. debuggerd_exec Datei deklariert als:
type debuggerd_exec, exec_type, file_type;
Dies bedeutet, dass ein Verfahren die Datei benötigen die Erlaubnis entweder auf der Art debuggerd_exec oder auf den Attributen exec_type oder file_type lesen würde zu lesen versuchen.
die aktuelle Spitze des AOSP Master Verwendung zum Zeitpunkt dieser Antwort und das Mittagessen Ziel aosp_x86_64-ger, können wir was „Quelldomänen“ tatsächlich sehen diese Datei mit folgendem sesearch Befehl lesen:
$ sesearch -A -t debuggerd_exec -c file -p read $OUT/root/sepolicy
allow debuggerd debuggerd_exec:file { read open getattr entrypoint execute };
allow debuggerd exec_type:file { read lock ioctl open getattr };
allow init debuggerd_exec:file { read getattr open execute };
allow perfprofd exec_type:file { read lock ioctl open getattr };
Wenn Sie die Quelldomänen bemerken (die erste Sache nach dem Zulassen), ist keine davon Shell oder nicht vertrauenswürdig. Bei nicht gerooteten Benutzer-Builds kann man ohne Exploit nur Code in den nicht vertrauenswürdigen App- oder Shell-Domänen ausführen (das stimmt nicht genau, aber die Details sind nicht wirklich wichtig).
Außerdem, selbst wenn nicht vertrauenswürdige_App Zugriff hatte, müssen Sie beachten, dass MLS manchmal den Zugriff verhindern kann, selbst wenn die Suche zeigt, dass Sie Zugriff haben. SE Linux unter Android verwendet sowohl Type Enforcement (Regeln zulassen) als auch MLS (mls_constrain-Regeln), um Isolation und Sandbox-Verstärkung zu bieten.