Mein Handy hat seit einigen Tage nur noch Probleme bereitet und viele Apps brachen gleich nach dem Start ab. Bei Aurora-Store war zum Beispiel die Konfiguration weg und nach der erfolgreichen Anmeldung stürzte die App ab.
Seit einigen Monaten hatte ich schon beobachtet, dass immer wieder nach einem Neustart Apps verschwunden waren, die ich kurz zuvor aktualisiert hatte. Meine Galaxy S2 zeigte also deutliche Auflösungserscheinungen und ich befürchtete, dass der Speicher die Ursache ist.
Allerdings bin ich bei der Suche mit adb logcat auf Einträge wie diese hier
gestoßen:
10-23 10:46:55.288 2365 2365 W android.bg: type=1400 audit(0.0:279): avc: denied { rename } for name="1561477294631" dev=mmcblk0p10 ino=103961 scontext=u:r:system_server:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
10-23 10:46:55.297 2352 2365 W AtomicFile: Couldn't rename file /data/system/usagestats/0/yearly/1561477294631 to backup file /data/system/usagestats/0/yearly/1561477294631.bak
10-23 10:46:55.293 2365 2365 W android.bg: type=1400 audit(0.0:280): avc: denied { write } for name="1561477294631" dev=mmcblk0p10 ino=103961 scontext=u:r:system_server:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
10-23 10:46:55.302 2352 2365 E UsageStatsService: User[0] Failed to persist active stats
10-23 10:46:55.302 2352 2365 E UsageStatsService: java.io.IOException: Couldn't create directory /data/system/usagestats/0/yearly/1561477294631
10-23 10:46:55.298 2365 2365 W android.bg: type=1400 audit(0.0:281): avc: denied { rename } for name="app_idle_stats.xml" dev=mmcblk0p10 ino=62330 scontext=u:r:system_server:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
10-23 10:46:55.304 2352 2365 W AtomicFile: Couldn't rename file /data/system/users/0/app_idle_stats.xml to backup file /data/system/users/0/app_idle_stats.xml.bak
10-23 10:46:55.298 2365 2365 W android.bg: type=1400 audit(0.0:282): avc: denied { write } for name="app_idle_stats.xml" dev=mmcblk0p10 ino=62330 scontext=u:r:system_server:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
10-23 10:46:55.306 2352 2365 E AppIdleHistory: Error writing app idle file for user 0
10-23 10:46:55.298 2365 2365 W android.bg: type=1400 audit(0.0:283): avc: denied { rename } for name="screen_on_time" dev=mmcblk0p10 ino=55631 scontext=u:r:system_server:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
10-23 10:46:55.311 2352 2365 W AtomicFile: Couldn't rename file /data/system/screen_on_time to backup file /data/system/screen_on_time.bak
10-23 10:46:55.303 2365 2365 W android.bg: type=1400 audit(0.0:284): avc: denied { write } for name="screen_on_time" dev=mmcblk0p10 ino=55631 scontext=u:r:system_server:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
Diese führten mich zu dem Verzeichnis /data/system in dem mehrere Dateien keinen SELinux-Kontext mehr hatten, aber andere hatten einen Kontext zugewiesen:
$ ls -lZR /data/system
-rw------- 1 system system u:object_r:unlabeled:s0 90638 2019-01-05 17:32 appops.xml
-rw------- 1 system system u:object_r:unlabeled:s0 108184 2019-07-02 10:14 batterystats-checkin.bin
-rw------- 1 system system u:object_r:unlabeled:s0 26401 2019-07-02 10:14 batterystats-daily.xml
-rw------- 1 system system u:object_r:system_data_file:s0 228 2019-10-16 10:22 device_policies.xml
-rw------- 1 system system u:object_r:system_data_file:s0 160 2019-10-07 17:37 deviceidle.xml
So habe ich mir mit adb shell su -c "'ls -ZRl /data/system'" alle
problematischen Dateien rausgesucht (Emacs mit C-u M-! mit
delete-matching-lines macht's leicht) und diesen mit chcon
u:object_r:system_data_file:s0 … den Kontext zugewiesen. Damit sah die Welt
schon wieder etwas besser aus.
Allerdings fielen mir bei logcat auch andere Fehlermeldungen auf und so habe ich obigen ls-Befehl auf das komplette /data losgelassen. Für die Dateien ohne Kontext habe ich dann den Kontext der Dateien benutzt, die im selben Verzeichnis lagen.
10-23 17:33:05.709 14384 14384 W SharedPreferenc: type=1400 audit(0.0:103): avc: denied { getattr } for path="/data/user_de/0/com.google.android.inputmethod.latin/shared_prefs/com.google.android.inputmethod.latin_ueh.xml" dev=mmcblk0p10 ino=74062 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
Falsche Eigentümer der alten Daten
Allerdings starteten nicht alle Apps nach der Neuinstallation. Im Log ist mir aufgefallen, dass es immer noch Zugriffsfehler gab. Die Prozesse wurden mit dem falschen Benutzer gestartet, wie mir dann beim Blick ins Dateisystem auffiel. Der ActivityManager startet den Prozess als u0a101, aber die Dateien gehörten u0_a128.
10-23 15:26:11.869 2350 3682 I ActivityManager: Start proc 14515:im.vector.alpha/u0a101 for activity im.vector.alpha/im.vector.activity.VectorLauncherActivity
10-23 15:26:12.535 14515 14515 W ContextImpl: Failed to ensure /data/user/0/im.vector.alpha/files: mkdir failed: EACCES (Permission denied)
10-23 15:26:12.602 14515 14532 W ContextImpl: Failed to ensure /data/user/0/im.vector.alpha/shared_prefs: mkdir failed: EACCES (Permission denied)
10-23 15:26:12.615 14515 14515 W ContextImpl: Failed to ensure /data/user/0/im.vector.alpha/shared_prefs: mkdir failed: EACCES (Permission denied)
…
10-23 15:26:12.631 14515 14532 E SQLiteLog: (14) cannot open file at line 32460 of [69906880ce]
10-23 15:26:12.631 14515 14532 E SQLiteLog: (14) os_unix.c:32460: (13) open(/data/user/0/im.vector.alpha/databases/androidx.work.workdb) -
10-23 15:26:12.670 14515 14532 E SQLiteDatabase: Failed to open database '/data/user/0/im.vector.alpha/databases/androidx.work.workdb'.
10-23 15:26:12.670 14515 14532 E SQLiteDatabase: android.database.sqlite.SQLiteCantOpenDatabaseException: unknown error (code 14): Could not open database
10-23 15:26:12.670 14515 14532 E SQLiteDatabase: at android.database.sqlite.SQLiteConnection.nativeOpen(Native Method)
# ls -l /data/data/im.vector.alpha/
total 60
drwxrwx--x 2 u0_a128 u0_a128 4096 2019-10-04 10:07 app_textures
drwx------ 4 u0_a128 u0_a128 4096 2019-10-04 10:07 app_webview
drwxrwx--x 2 u0_a128 u0_a128 4096 2019-10-16 23:28 cache
drwxrwx--x 2 u0_a128 u0_a128 4096 2019-10-04 10:06 code_cache
drwxrwx--x 2 u0_a128 u0_a128 4096 2019-10-04 10:07 databases
drwxrwx--x 8 u0_a128 u0_a128 4096 2019-10-04 13:26 files
lrwxrwxrwx 1 root root 35 2019-10-23 11:33 lib -> /data/app/im.vector.alpha-2/lib/arm
drwxrwx--x 2 u0_a128 u0_a128 4096 2019-10-04 22:25 shared_prefs
# ls -dl /data/data/im.vector.alpha/
drwx------ 9 u0_a128 u0_a128 4096 2019-10-23 11:33 /data/data/im.vector.alpha/
# ls -l /data/user_de/0/im.vector.alpha/
drwxrwx--x 2 u0_a128 u0_a128 4096 2019-10-17 18:49 code_cache
Daher bin ich einmal beherzt mit chmod -R u0_a101:u0_a101
/data/user_de/0/im.vector.alpha /data/data/im.vector.alpha über beide
Verzeichnisse hinweg und schon klappte es mit der App und sie hatte Zugriff auf
die alten Daten.
Fazit
Ohne den Zugriff auf das System wäre mein Handy Schrott gewesen. Ich kämpfe zwar schon länger mit der geringen Rechenleistung, ungenügend RAM und Speicher, aber mein 8-jahre-altes Galaxy S2 funktioniert noch ausreichend im Alltag. Die fehlerhaften Rechte hätten es aber spätestens jetzt unbrauchbar gemacht und ein Nicht-Bastler wäre an der Stelle aufgeschmissen und hätte sich nur ein neues Gerät besorgen können, obwohl die Hardware noch voll einsatzfähig ist.
Für SELinux hat sich ein deutlicher Nachteil gezeigt: Wenn die Kennzeichnungen im Dateisystem verloren gehen – aus was für Gründen auch immer – geht nichts. Bei AppArmor hätte man im Gegensatz dazu eine beschädigte Profildatei, die sich beim Start nicht laden ließe. Daran wäre klar zu erkennen, dass etwas defekt ist. Bei SELinux sind fehlende Kennzeichnungen aber ein gültiger Zustand, womit der Fehler nicht so leicht auffällt. Außerdem hat sich bei dem Herumsuchen im Dateisystem gezeigt, dass die zentrale Speicherung der Profilinformationen bei AppArmor übersichtlicher ist.