On 07/13/2016 12:22 PM, Roman Mazur wrote: >>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?
external/sepolicy/mls defines different constraints on app data files versus other files. For app data files, which are labeled with the same categories as the app process, we can impose a constraint on open that requires equivalence and omit constraints on read and write, thereby allowing passing and use of open file descriptors while blocking direct open of any file that has a different category set. For other files, we cannot do that without blocking any form of open to the file (even if only for read access) since it will not have the same categories; we instead use conventional MLS constraints on read and write, which will generally allow read access and prohibit write access (unless the file type is a mlstrustedobject). > > 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? We generally would not create a MLS-aware daemon per se but instead just a SELinux-aware daemon. Examples in AOSP today include the init property service, servicemanager, keystore, debuggerd, and drmserver; they fetch the security context of their client via getpeercon or getpidcon, invoke SELinux permission checks via selinux_check_access, and possibly manage or lookup object security contexts of their own. _______________________________________________ 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.
