[prev in list] [next in list] [prev in thread] [next in thread] 

List:       seandroid-list
Subject:    Re: Preventing Transfer of Binder Handles
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2015-02-27 17:46:10
Message-ID: 54F0AD62.7080607 () tycho ! nsa ! gov
[Download RAW message or body]

On 02/27/2015 12:21 PM, E. Paul Ratazzi wrote:
> I apologize for my previous incomplete message.  Premature send!  Here
> is the full question:
> 
> Hello,
> 
> I'm doing some experiments with the native servicemanager and I have a
> couple of questions on how SELinux policy might help harden my
> prototype, in particular regarding the dispatch of capabilities for
> system services.
> 
> I am familiar with selinux_binder_transfer_binder() in hooks.c which is
> used in the kernel binder driver to check to see if a transfer between
> two sids is allowed by policy.  This is kind of what I'm looking for,
> but I need to understand how to add more discernment regarding the
> allow/deny decision.
> 
> Specifically, I would like to prevent certain apps from transferring
> system service capabilities to other apps.  In other words, I want the
> context manager to be the ONLY way for an app to get the capability for
> a system service.
> 
> I realize normal apps would just use context manager to get handles. 
> This is fine; I am really looking at a theoretical corner case where a
> malicious app might try to bypass the new logic I'm introducing to
> servicemanager. In fact, I'm not even sure this scenario of one app
> passing a service handle to another app is possible since I can't seem
> to get such a demonstration working.
> 
> Is policy the right place to do this?  Or am I looking at some custom
> mods to the binder driver to block only certain transactions depending
> on the contents of the parcel?

First, as you may have noticed, userspace SELinux access checks have
been added to the servicemanager that can be used to control adding
(registering) and finding (looking up) binder references for a given
name, as well as a generic control over the ability to list all of the
services.  In 5.x, I believe that only the adding/registering of
services is being restricted while find and list are allowed by all,
whereas there has been ongoing work in master to lock down find and list
access as well.

Second, the SELinux binder_transfer_binder hook and binder transfer
permission originally supported the scenario you describe but we had to
change it, see:
 http://marc.info/?t=137438440700037&r=1&w=2

To do what you describe you would need to find some way to identify the
owner of the binder reference/node, pass that to the hook, and implement
a new permission check between the sender (from) task and the owner of
the binder reference/node, which is what our binder transfer permission
originally did.  To do that, you would need to store the owner
information in the binder_node when it is created so it is available
even if the owning task has died.  Then your policy could specify that
e.g. app domains can transfer binder references for app-created objects
but not for objects created by system_server or other system services.
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]