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:
> 
> Change-Id: Ie3863616018b83f66aad9981b4fb1f07d006b18b
> ---
>  mls               |    5 +++--
>  radio.te          |    2 ++
>  servicemanager.te |    2 ++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/mls b/mls
> index a4c214b..9764b8e 100644
> --- a/mls
> +++ b/mls
> @@ -124,5 +124,6 @@ mlsconstrain ipc_class_set w_ipc_perms
>  # 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.

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

Reply via email to