Ich würde auf meinem Fairphone e/os Handy gerne die Gematik E-Rezept App nutzen um meine Arztrezepte prüfen zu können.
Wenn ich über den App Shop die DAK ePA App und DAK App installiere (die wegen meiner Krankenkasse DAK scheinbar? Voraussetzung für die Authentifizierung der E-Rezept App sind) verhält es sich wie folgt:
- die DAK ePA App startet nicht sondern schließt sich sofort nach dem Start wieder ohne weiteren Hinweis.
- die DAK App öffnet sich zwar meldet jedoch “This app cannot run because the environment is not secure and your data may be at risk”
ich habe beide Apps über die “App Lounge” von eOS installiert.
Vielleicht weiß hier ja ein deutscher Benutzer Rat, da diese Apps und die Gematik E-Rezept App in Deutschland ja relativ hilfreich (unverzichtbar) sind, wenn man z.b. als chronischer Patient regelmässig Arztrezepte einlösen will / muss.
Versionen:
…habe das gleiche Problem mit der DAK App auf dem fp5 und vor ein paar Tagen mit dem Support der DAK telefoniert und den Fall ausführlich beschrieben. Man wollte sich kümmern und ich bin gespannt…
dass man von DAK Seite etwas tut, um gezielt eine eher kleine Randgruppe von /e/OS Benutzern zufrieden zu stellen, kann ich mir ehrlich gesagt kaum vorstellen.
Mir hatte man am Telefon der DAK gesagt, dass Sicherheit für die DAK App sehr wichtig wäre und ich eher darüber nachdenken sollte, ein neues Telefon oder Betriebssystem zu suchen.
Mich persönlich interessiert eigentlich nur die E-Rezept App und ich werde prüfen ob es nicht irgend einen Weg gibt diese App ohne die DAK Apps sauber nutzen zu können um seine Rezepte prüfen zu können.
(die DAK ePA App kommt vom gleichen Publisher wie einige deutsche Krankenkassen, siehe ePA elektronische Patientenakte für einen älteren Thread dazu)
Beide DAK Apps haben den gleichen init*, prüfen Umgebungsvariablen (build.prop) / Build-Fingerprints und sind mindestens unglücklich mit ro.debuggable - Klassiker. Es wird noch mehr geprüft, muss also nicht das ausschlaggebende sein.
Welchem build-channel (stable od. dev) folgst Du mit deinem Gerät @funkrusher ? FP3 stable builds könnten eigentlich (bin da nicht aktuell) normale user-builds sein (statt userdebug). Dort sollte der check durch gehen wenn es nicht noch was anderes ist.
Ich spekuliere ..
… viele Android EntwicklerInnen können gar nicht benennen was die konkrete Gefahr ist (von ro.debuggable oder ro.secure) derer sie sich als Platformbetreiber aussetzen würden bzw vor denen sie NutzerInnen durch das nicht-erlauben schützen.
* relevante Teile der Appstarts
E de.dak.dak_app: Not starting debugger since process cannot load the jdwp agent.
...
I Fingerprint: [20240513-202406061301 b7:b7 33 Fairphone/FP3/FP3:13/6.A.023.1/gms-497e9bef:user/release-keys blocked]
E SELinux : avc: denied { find } for pid=7365 uid=10169 name=н%е*Ñ^е&Ñ/в$и@Ñ scontext=u:r:untrusted_app:s0:c169,c256,c512,c768 tcontext=u:object_r:default_android_service:s0 tclass=service_manager permissive=0
W de.dak.dak_app: type=1400 audit(0.0:111): avc: denied { read } for name="u:object_r:userdebug_or_eng_prop:s0" dev="tmpfs" ino=15555 scontext=u:r:untrusted_app:s0:c169,c256,c512,c768 tcontext=u:object_r:userdebug_or_eng_prop:s0 tclass=file permissive=0 app=de.dak.dak_app
W libc : Access denied finding property "ro.debuggable"
W libc : Access denied finding property "ro.vendor.boot.warranty_bit"
W libc : Access denied finding property "ro.vendor.warranty_bit"
...
D AndroidRuntime: Shutting down VM
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: de.dak.dak_app, PID: 7365
...
E AndroidRuntime: Caused by: java.lang.RuntimeException: DP: 777 08322e3000062b
...
E AndroidRuntime: at de.dak.dak_app.ProtectedDAKApplication.onCreate(Unknown Source:41)
E AndroidRuntime: ... 11 more
I ActivityManager: Showing crash dialog for package de.dak.dak_app u0
# epa app
W a.dakGesundheit: JIT profile information will not be recorded: profile file does not exist.
...
I Fingerprint: [20240222-202403191949 b7:b7 33 Fairphone/FP3/FP3:13/6.A.023.1/gms-497e9bef:user/release-keys blocked]
W a.dakGesundheit: type=1400 audit(0.0:169): avc: denied { read } for name="drivers" dev="proc" ino=4026531853 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:proc_tty_drivers:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
W a.dakGesundheit: type=1400 audit(0.0:170): avc: denied { read } for name="modules" dev="proc" ino=4026532117 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:proc_modules:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
W libc : Access denied finding property "ro.debuggable"
W a.dakGesundheit: type=1400 audit(0.0:171): avc: denied { read } for name="devices" dev="proc" ino=4026531974 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:proc:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
W libc : Access denied finding property "ro.vendor.warranty_bit"
W a.dakGesundheit: type=1400 audit(0.0:172): avc: denied { read } for name="u:object_r:userdebug_or_eng_prop:s0" dev="tmpfs" ino=15555 scontext=u:r:untrusted_app:s0:c168,c256,c512,c768 tcontext=u:object_r:userdebug_or_eng_prop:s0 tclass=file permissive=0 app=com.rise_world.epa.dakGesundheit
...
D AndroidRuntime: Shutting down VM
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.rise_world.epa.dakGesundheit, PID: 11680
...
E AndroidRuntime: Caused by: java.lang.RuntimeException: DP: 777 08322e3000062b
E AndroidRuntime: at com.rise_world.epa.ProtectedFdVApplication.cihsaDntld(Native Method)
E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
...
E AndroidRuntime: at com.rise_world.epa.ProtectedFdVApplication.onCreate(Unknown Source:41)
1 Like
Hi @tcecyk
danke dir für die Recherche.
Ich folge FP3 stable builds.
- Aktuelle Version:
- /e/OS 2.1-t-20240603406607-stable-FP3
Es muss also evtl. noch etwas anderes sein bzw. wenn du es mit Debug getestet hast und der Check wegen Debug nicht durchgeht ist es bisschen schade, weil man ja ohne Debug glaub nicht an die Logs rankommt die du gepostet hast und somit kann ich wohl keine Logs posten, wenn ich auf Stable bin. Dazu kenne ich mich aber auch zu wenig aus.
ja, der init bei dir wird anders aussehen. adb kannst du anmachen trotzdem auch bei einem user-build, wird nur weniger ausführlich sein wegen dem debug-flag. Ich frage mich ob FP3-stable echte user-builds sind.
Werde aus meiner eigenen Logausgabe nicht ganz schlau, das “Access denied” könnte den App init genauso stören wie der Wert der in dem properties-flag steckt bei erfolgreichem auslesen. Kenne den Patch nicht der das Verhindern des Auslesens von Properties möglich macht… oder sind das einfach zu weitreichende selinux regeln die das verhindern?