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.
And add platformappdomain to binderservicedomain?
Do we actually want to upstream this change given that system_server is
still routing so much through binder? Are there plans to make
system_server an object manager?
That is essentially what the Flask middleware MAC is intended to
address.
--
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.
