On Fri, 2012-09-28 at 11:27 -0400, Joshua Brindle wrote: > Stephen Smalley wrote: > > On Fri, 2012-09-28 at 11:10 -0400, Joshua Brindle wrote: > >> Stephen Smalley wrote: > >>> On Fri, 2012-09-28 at 10:55 -0400, Joshua Brindle wrote: > >>>> As of right now, if you want a separate app domain (no binder > >>>> communications allowed outside of the domain) you have to reproduce all > >>>> the rules for the appdomain attribute for the new domain. This isn't > >>>> ideal, and having to track appdomain changes, etc, etc. > >>>> > >>>> My first thought was to make a template that replicated all of the > >>>> appdomain rules (which would enlarge the policy every time it was used) > >>>> but it occurred to me this morning that we aren't really utilizing the > >>>> constraints for binder. I quickly tested this on my phone this morning > >>>> and it appears to work. > >>>> > >>>> I had to make servicemanager and radio binder services, I don't know if > >>>> that was the right thing to do but the macro description seemed to match: > >>>> > >> <snip> > >> > >>>> # Presently commented out, as apps are expected to call one another. > >>>> # This would only make sense if apps were assigned categories > >>>> # based on allowable communications rather than per-app categories. > >>>> -#mlsconstrain binder call > >>>> -# (l1 eq l2 or t1 == mlstrustedsubject or t2 == > >>>> mlstrustedsubject); > >>>> +mlsconstrain binder call > >>>> + (l1 eq l2 or t1 == mlstrustedsubject or t2 == mlstrustedsubject > >>>> or t1 == t2 > >>>> + or t1 == platformappdomain or t2 == platformappdomain > >>>> or t2 == binderservicedomain); > >>> Bill tried using this constraint earlier but found it doesn't actually > >>> prevent Intents from being sent across levels. They all go through the > >>> system_server, so it just looks like A -> system_server and > >>> system_server -> B. Kernel doesn't see the direct A -> B connection. > >>> > >> In what cases? I definitely see plenty of binder calls between the > >> domains when I separate them (both this way and the way I was doing it > >> before). Granted if the system_server does that at all it has to be > >> enforce the separation but I'm wondering what I'm currently letting > >> through. > > > > There are some direct calls, yes, but AMS routes Intents and deals with > > Broadcasts IIUC. > > > > BTW, what's the advantage of adding further exceptions to the constraint > > vs. just making those domains mlstrustedsubjects? If they can take > > binder IPC from any level, then they may also have to deal with open fds > > passed by the caller that may be created at any level. Or if they truly > > don't require full mls exemption, I'd say introduce a new > > mlstrustedbinder attribute and put that on all of the relevant domains. > > > > I looked around for an attribute that was already used for binder > services and assumed that platformappdomain would need to be exempt as > well. What is the advantage to combining those 2 domains into > mlstrustedbinder?
We already mark platform app domains with mlstrustedsubject in platform_app_domain() so that one should be covered. Adding it to binder_service() likely also makes sense. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with the words "unsubscribe seandroid-list" without quotes as the message.
