On 02/27/2015 12:21 PM, E. Paul Ratazzi wrote: > I apologize for my previous incomplete message. Premature send! Here > is the full question: > > Hello, > > I'm doing some experiments with the native servicemanager and I have a > couple of questions on how SELinux policy might help harden my > prototype, in particular regarding the dispatch of capabilities for > system services. > > I am familiar with selinux_binder_transfer_binder() in hooks.c which is > used in the kernel binder driver to check to see if a transfer between > two sids is allowed by policy. This is kind of what I'm looking for, > but I need to understand how to add more discernment regarding the > allow/deny decision. > > Specifically, I would like to prevent certain apps from transferring > system service capabilities to other apps. In other words, I want the > context manager to be the ONLY way for an app to get the capability for > a system service. > > I realize normal apps would just use context manager to get handles. > This is fine; I am really looking at a theoretical corner case where a > malicious app might try to bypass the new logic I'm introducing to > servicemanager. In fact, I'm not even sure this scenario of one app > passing a service handle to another app is possible since I can't seem > to get such a demonstration working. > > Is policy the right place to do this? Or am I looking at some custom > mods to the binder driver to block only certain transactions depending > on the contents of the parcel?
First, as you may have noticed, userspace SELinux access checks have been added to the servicemanager that can be used to control adding (registering) and finding (looking up) binder references for a given name, as well as a generic control over the ability to list all of the services. In 5.x, I believe that only the adding/registering of services is being restricted while find and list are allowed by all, whereas there has been ongoing work in master to lock down find and list access as well. Second, the SELinux binder_transfer_binder hook and binder transfer permission originally supported the scenario you describe but we had to change it, see: http://marc.info/?t=137438440700037&r=1&w=2 To do what you describe you would need to find some way to identify the owner of the binder reference/node, pass that to the hook, and implement a new permission check between the sender (from) task and the owner of the binder reference/node, which is what our binder transfer permission originally did. To do that, you would need to store the owner information in the binder_node when it is created so it is available even if the owning task has died. Then your policy could specify that e.g. app domains can transfer binder references for app-created objects but not for objects created by system_server or other system services. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
