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.
--
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.
