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.

On Tue, Oct 21, 2014 at 6:28 PM, William Roberts <bill.c.robe...@gmail.com>
wrote:

>
> On Oct 21, 2014 8:02 AM, "Joshua Brindle" <brin...@quarksecurity.com>
> wrote:
> >
> > Tal Palant wrote:
> >>
> >> what do you mean by intent firewall?
> >>
> >> and how can i tell if applications talk using system_server over binder?
> >
> >
> > Look at external/sepolicy/ifw.xml in your SEAndroid tree.
> >
> > Practically all applications talk to system_server over binder, almost
> all framework calls that require another service go through system_server.
>
> To put this into other terms, when you send intents or broadcasts, the
> data goes from the creator, to system server, then to the recipient. The
> kernel sees a binder from originator to system server, then to recipient.
> So it just looks like normal flow, the only one with full transactional
> awareness is system server, so to control these, you need logic in system
> server. That logic is intent firewall.
>
> IIRC, this applies partially to content providers for resolution of the
> service, but once routing is established its direct binder between provider
> and consumer. I haven't looked at that in a couple of years so I may be
> wrong.
>
> >
> >> On Tue, Oct 21, 2014 at 5:53 PM, Joshua Brindle
> >> <brin...@quarksecurity.com <mailto:brin...@quarksecurity.com>> wrote:
> >>
> >>     William Roberts wrote:
> >>
> >>
> >>         On Oct 21, 2014 7:37 AM, "Tal Palant" <tal.pal...@gmail.com
> >>         <mailto:tal.pal...@gmail.com>
> >>         <mailto:tal.pal...@gmail.com <mailto:tal.pal...@gmail.com>>>
> wrote:
> >>         >
> >>         >  How can i block specific ipc calls between processes (in
> theory)?
> >>         >
> >>         >  what kind of policy do i need to define in order to do so?
> >>         >
> >>         >
> >>         >  On Mon, Oct 20, 2014 at 4:10 PM, Stephen Smalley
> >>         <s...@tycho.nsa.gov <mailto:s...@tycho.nsa.gov>
> >>         <mailto:s...@tycho.nsa.gov <mailto:s...@tycho.nsa.gov>>> wrote:
> >>         > >
> >>         > > On 10/18/2014 05:24 AM, Tal Palant wrote:
> >>         > > > Hello all,
> >>         > > >
> >>         > > > i'm trying to get a better understanding on how SEAndroid
> can
> >>         effect the
> >>         > > > ipc in Android.
> >>         > > >
> >>         > > > Can SEAndroid prevent applications from sending binder to
> other
> >>         > > > applications?
> >>         > > >
> >>         > > > Thanks in advance,
> >>         > >
> >>         > > Yes, we added security hooks to the kernel binder driver,
> and
> >>         therefore
> >>         > > SELinux can mediate binder IPC.  However, in practice, apps
> >>         are expected
> >>         > > to be able to call each other, and much IPC is indirect
> >>         through the
> >>         > > system_server, so the current policy is not enforcing a
> >>         particular goal
> >>         > > in this regard
> >>
> >>         You can either use type enforcement by placing the apps in new
> >>         domains
> >>         and not allowing any binder class permissions.
> >>
> >>         You can use mls, and enable the mls constraint in the policy
> >>         file mls.
> >>         Look for a commented out constraint that references binder.
> >>
> >>
> >>     Of course, none of that stops apps from talking through
> >>     system_server over binder. For that you'll need to use the intent
> >>     firewall.
> >>
> >>
> >>
> >>
> >> --
> >> טל פולו פלנט
> >> כי שם כזה יש רק אחד
> >
> >
>



-- 
טל פולו פלנט
כי שם כזה יש רק אחד
_______________________________________________
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.

Reply via email to