On 12/16/2015 10:51 PM, Mendell, Mark P wrote:
I am playing with some changes to the system, using Android 6.0. I am getting log messages like:12-16 22:11:27.051 10233 10233 W android.process.media: type=1400 audit(0.0:972): avc: denied { write } for comm=45786163742050726F66696C652042 name="XXX" dev="dm-0" ino=16300 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:YYY:s0 tclass=file permissive=0 I find this to be confusing, as I have an explicit line in the devices/…/sepolicy/untrusted_app.te: allow untrusted_app YYY:dir { search getattr }; allow untrusted_app YYY:file { rw_file_perms }; I also see the same problem with platform_app. Other uses of YYY work perfectly for me (I spent quite a bit of time figuring this out by trial and error). Only untrusted_app and platform_app are a problem. Can anyone help me figure this out? Are untrusted_app and platform_app treated differently? I searched the generated policy.conf file, but didn’t see anything that looked like it had anything that would override the allows above.
In M, apps and their data files are assigned an automatically generated category set (c512,c768 above) derived from their user ID in order to isolate the processes and files of different users from each other. This prevents cross-user or cross-profile access to /proc/pid files and app data files, even if world-readable or -writable (sharing is still possible by having the owning app open the file itself and pass the file descriptor over binder or local socket IPC to another app, but direct open is prohibited). This separation is currently applied to untrusted apps and platform apps as a result of specifying levelFrom=user in the seapp_contexts configuration.
What is this file and why does it need to be globally writable? What are you doing to ensure its protection if it is globally writable?
As long as YYY is not app_data_file, you can "fix" the denial by adding ", mlstrustedobject" to the type declaration of YYY, e.g.
type YYY, <any other attributes>, mlstrustedobject; But that doesn't address the question of whether this is safe to do. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
