>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 };Thanks, I missed that w_file_perms (and subsequently rw_file_perms) macros includes the open vector. >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: Got it, thanks! But speaking about the sharing scenario between apps, isn't it the same case I have with my daemon (when it opens a file descriptor and passes it to an app)? Why does it work for apps from different profiles/users? And thanks for the clarification regarding the audit message. >Wouldn't make more sense to make the daemon MLS aware and label these files with the category set of the requestor? There are multiple apps that can access those files. And currently this access is granted using Android permissions model (the daemon checks if caller has the permission before opening a file). But my plan is to define a custom domain for these apps that will be assigned basing on application signature. And then use MLS to prevent sharing the files with other apps. Would you point me to an example of an MLS aware daemon? Thanks a lot for your help! On Tue, 12 Jul 2016 at 22:20 Roberts, William C <william.c.robe...@intel.com> wrote: > > > > -----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-l...@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-l...@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. > -- -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups "android-porting" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-porting+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
