On 10/30/2014 11:19 AM, Tal Palant wrote: > So to clarify if i put each application in a separate domain i can use this > to block binder access to other applications or only to all binder classes > including through the system? > > if so then the application could not communicate via IPC at all which will > greatly damage her abilities.
The SELinux binder checks are between the caller and the callee domains; policy has to allow A B:binder call; in order for A to perform a binder IPC to B. Typically this is written in policy using a macro, binder_call() that also sets up the rules to permit passing binder references (object capabilities) across the call and in the reply, as well as passing open file descriptors across the call. Further, the current policy has devolved to just allowing all possible pairings by using type attributes, as in binder_call(appdomain, bindservicedomain) and binder_call(appdomain, appdomain), since that is the normal way of things in Android. If we had a specific use case where a given app or binder service should only be callable by another specific app, then this could be changed. Those checks however are only for the direct calls; since we allow all apps to call system_server and vice versa, all apps can send Intents via the system_server to one another. IntentFirewall seems to be more of a Intent payload-based firewall than a peer-to-peer check. You really just need to dive into the code and experiment with policy if you want to fully understand it. _______________________________________________ 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.
