> -----Original Message----- > From: Seandroid-list [mailto:seandroid-list-boun...@tycho.nsa.gov] On Behalf > Of Stephen Smalley > Sent: Tuesday, July 12, 2016 12:15 PM > To: mazur.ro...@gmail.com; android-porting <android- > port...@googlegroups.com>; seandroid-list@tycho.nsa.gov > Subject: Re: [android-porting] Strange AVC Denial > > On 07/12/2016 11:57 AM, Roman Mazur wrote: > > I'm working on a custom build based on Android 6.0.1 for Nexus 7. This > > custom build adds a special daemon that is started from init.rc and > > exposes some API to applications. Particularly, one of available > > methods creates a new file at /data/daemon_dir and returns a file > > descriptor making it possible to write to this file from an app. > > > > The daemon has its own SELinux context (here it's named custom_daemon). > > And /data/daemon_dir has custom_daemon_file context. There are > > sepolicy rules that grant file creation to the daemon and file writes > > to untrusted_app. > > > > The configuration described above worked on Android 5. But after > > merging with Android 6, I'm getting the following denial: > > > > 07-11 21:57:46.735 13389-13389/? W/Binder_2: type=1400 audit(0.0:945): > > avc: denied { write } for path="/data/daemon_dir/some_file" > > dev="mmcblk0p30" ino=496817 scontext=u:r:untrusted_app:s0:c512,c768 > > tcontext=u:object_r:custom_daemon_file:s0 tclass=file permissive=0 > > > > > > Here are the rules that should allow the operation: > > > > allow untrusted_app custom_daemon_file:file rw_file_perms; allow > > untrusted_app custom_daemon_file:dir r_dir_perms; > > (cc seandroid-list) > > Assuming that you only want to allow apps to read and write files passed to > them > explicitly by your daemon and not to directly open files in this directory, > you > should only have: > allow untrusted_app custom_daemon_file:file { read write getattr }; > > In particular, you would not need to allow open permission to file nor any > permissions to the directory in this usage model, and not allowing those > permissions would be more secure as it would prevent apps from directly > accessing any of those files without going through your daemon. > > > allow custom_daemon custom_daemon_file:dir create_dir_perms; allow > > custom_daemon custom_daemon_file:file create_file_perms; > > > > > > An interesting thing in this denial report is that scontext is > > untrusted_app. But the denial is logged for the daemon process (13389 > > is one of its thread IDs and Binder_2 is a name of the binder thread > > that handles the API call). > > > > I believe this mismatch is what is causing the denial but cannot > > understand why this happens and how this can be fixed. > > No, the denial is caused by the fact that the app is running with categories > (c512,c768) and the file is not labeled with the same categories. You can > allow this > by adding the mlstrustedobject attribute to your type: > type custom_daemon_file, file_type, data_file_type, mlstrustedobject;
Wouldn't make more sense to make the daemon MLS aware and label these files with the category set Of the requestor? This would prevent sharing the file with a different untrusted_app, unless that's A possible part of your design. Granted, the service would need mlstrustedsubject to manage these, but as long as you don't allow the service access to app_data_files (IIRC that's a neverallow) or other things where MLS is used to further restrict access, then it should be ok. > > In 6.0, 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. > > With regard to the potentially misleading audit message, it is due to the > fact that > this check occurs when your daemon tries to pass the open file descriptor to > the > app, so it occurs while the daemon is the current process. Before > transferring the > descriptor into the app's descriptor table, SELinux checks whether the app is > allowed to use it. So the check is between the app's context and the file, > but > happens while the daemon is still the current process. > > _______________________________________________ > Seandroid-list mailing list > Seandroid-list@tycho.nsa.gov > To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. > To get help, send an email containing "help" to Seandroid-list- > requ...@tycho.nsa.gov. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
