On Fri, 2012-09-28 at 11:56 -0400, Joshua Brindle wrote: > Stephen Smalley wrote: > > On Fri, 2012-09-28 at 11:43 -0400, Joshua Brindle wrote: > >> Stephen Smalley wrote: > >>> 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. > >>> > >> So it should be: > >> > >> mlsconstrain binder call > >> (l1 eq l2 or t1 == mlstrustedsubject or t2 == mlstrustedsubject > >> or t1 == t2 or t2 == binderservicedomain); > > > > No, I'd add typeattribute $1 mlstrustedsubject to binder_service() in > > te_macros, and not change the constraint at all. I don't understand the > > t1 == t2 clause; that would mean that u:r:t1:s0:c1,c256 could call > > u:r:t1:<anylevel> or u:r:t2:s0:c1,c256 but could not call > > u:r:t2:s0:c2,c256? What kind of security goal are you trying to > > enforce? > > Containers, so untrusted_app:whatever can talk to untrusted_app:whatever > (as they can today) whereas untrusted_app can't talk to corporate_app.
Wouldn't it be simpler to disable levelFromUid=true for regular apps and then just explicitly assign different level= values for personal vs business apps using seinfo tags? And then just enable the binder MLS constraint as is? -- 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.
