SE Android and Finer Grained Permissions

SE Android and Finer Grained Permissions

[Jeffrey Walton]

Hi All,

Forgive my ignorance here.....

I was reading the slides at on SE Android at
http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf.

I see the slides point out "[Current Android suffers] limited
granularity, coarse-grained privilege." But I don't see where SE
Android corrected it. For example, it appears READ_PHONE_STATE still
encompasses reading a device serial number, IMEI, SIM ID, call state,
incoming calling number, etc.

Does SE Android remediate the coarse grained permissions?

Is an application installation still an "all or nothing" proposition
with respect to permissions? For example, can I approve an install and
later take away the WRITE_CONTACTS permission?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[James Carter]

On Sun, 2012-03-04 at 21:02 -0500, Jeffrey Walton wrote:
> Hi All,
> 
> Forgive my ignorance here.....
> 
> I was reading the slides at on SE Android at
> http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf.
> 
> I see the slides point out "[Current Android suffers] limited
> granularity, coarse-grained privilege." But I don't see where SE
> Android corrected it. For example, it appears READ_PHONE_STATE still
> encompasses reading a device serial number, IMEI, SIM ID, call state,
> incoming calling number, etc.
> 
> Does SE Android remediate the coarse grained permissions?
> 

No. Currently, the SE Android policy is only trying to ensure that the
existing Android security model is enforced. The Android permissions
work exactly the same way.

SE Android is still a work in progress. Our goal is to extend security
controls into the application frameworks of Android to better control
applications and that could eventually lead to finer-grained control
over resources currently controlled by Android permissions.

> Is an application installation still an "all or nothing" proposition
> with respect to permissions? For example, can I approve an install and
> later take away the WRITE_CONTACTS permission?
> 

As I mentioned above, SE Android currently does not change the Android
security model.
-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[Stephen Smalley]

On Mon, 2012-03-05 at 10:09 -0500, James Carter wrote:
> On Sun, 2012-03-04 at 21:02 -0500, Jeffrey Walton wrote:
> > Hi All,
> > 
> > Forgive my ignorance here.....
> > 
> > I was reading the slides at on SE Android at
> > http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf.
> > 
> > I see the slides point out "[Current Android suffers] limited
> > granularity, coarse-grained privilege." But I don't see where SE
> > Android corrected it. For example, it appears READ_PHONE_STATE still
> > encompasses reading a device serial number, IMEI, SIM ID, call state,
> > incoming calling number, etc.
> > 
> > Does SE Android remediate the coarse grained permissions?
> > 
> 
> No. Currently, the SE Android policy is only trying to ensure that the
> existing Android security model is enforced. The Android permissions
> work exactly the same way.
> 
> SE Android is still a work in progress. Our goal is to extend security
> controls into the application frameworks of Android to better control
> applications and that could eventually lead to finer-grained control
> over resources currently controlled by Android permissions.

Just to further clarify, SE Android does in fact address the limitations
of the kernel layer DAC security model, including overcoming its limited
granularity and coarse-grained privilege model (which is what you quoted
above from slide 5).  But addressing the application layer (aka
middleware layer) security model remains to be done, as noted on slide
46. Also, you may find the more recent talk we gave at the Android
Builders Summit to be helpful.  Links to the slides and video from that
talk are available on the wiki:
http://selinuxproject.org/page/SEAndroid#Presentations

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[Casey Schaufler]

On 3/4/2012 6:02 PM, Jeffrey Walton wrote:
> Hi All,
>
> Forgive my ignorance here.....
>
> I was reading the slides at on SE Android at
> http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf.
>
> I see the slides point out "[Current Android suffers] limited
> granularity, coarse-grained privilege." But I don't see where SE
> Android corrected it. For example, it appears READ_PHONE_STATE still
> encompasses reading a device serial number, IMEI, SIM ID, call state,
> incoming calling number, etc.
>
> Does SE Android remediate the coarse grained permissions?
>
> Is an application installation still an "all or nothing" proposition
> with respect to permissions? For example, can I approve an install and
> later take away the WRITE_CONTACTS permission?

I personally applaud the coarser granularity that the Android policy
has over the Fedora policy. I have long been critical of what I
consider to be excesses of granularity in SELinux. Do you really want
to see 900,000 lines of policy for a handset device? And before
someone starts to claim that the handset system software is somehow
smaller or less complex than the Fedora distribution I will point to
Stephen's note about the application enforced policy of Android.

Fine granularity in access controls are lots of fun for engineers
and seem like a good idea when you want to turn on a particular
facility and can't do so because the seemingly unrelated implications
are too dangerous. But it's a slippery slope, and I seriously doubt
that anyone would want to truly understand all the relationships
included in a policy for Android that matches the granularity of the
policy for Fedora.

But, that's my well known opinion, and as such you may wish to take
it with a grain of salt. I will be sad to see the Android policy grow
with the same unbridled exuberance as the Fedora and reference policies.


>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[Jeffrey Walton]

Hi Casey,

On Mon, Mar 5, 2012 at 8:02 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 3/4/2012 6:02 PM, Jeffrey Walton wrote:
>> Forgive my ignorance here.....
>>
>> I was reading the slides at on SE Android at
>> http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf.
>>
>> I see the slides point out "[Current Android suffers] limited
>> granularity, coarse-grained privilege." But I don't see where SE
>> Android corrected it. For example, it appears READ_PHONE_STATE still
>> encompasses reading a device serial number, IMEI, SIM ID, call state,
>> incoming calling number, etc.
>>
>> Does SE Android remediate the coarse grained permissions?
>>
>> Is an application installation still an "all or nothing" proposition
>> with respect to permissions? For example, can I approve an install and
>> later take away the WRITE_CONTACTS permission?
>
>
> I personally applaud the coarser granularity that the Android policy
> has over the Fedora policy. I have long been critical of what I
> consider to be excesses of granularity in SELinux. Do you really want
> to see 900,000 lines of policy for a handset device? And before
> someone starts to claim that the handset system software is somehow
> smaller or less complex than the Fedora distribution I will point to
> Stephen's note about the application enforced policy of Android.
>
> Fine granularity in access controls are lots of fun for engineers
> and seem like a good idea when you want to turn on a particular
> facility and can't do so because the seemingly unrelated implications
> are too dangerous. But it's a slippery slope, and I seriously doubt
> that anyone would want to truly understand all the relationships
> included in a policy for Android that matches the granularity of the
> policy for Fedora.
For what its worth, here's what I envision:

READ_PHONE_STATE gives the house away (confer:
http://android-permissions.org/ and the Permission Map). As a matter
of fact, Goolge forced the permission on *all* apps, whetehr it was
needed or not (confer:
http://stackoverflow.com/questions/1747178/android-permissions-phone-calls-read-phone-state-and-identity).

I want finer permissions than READ_PHONE_STATE. Perhaps
READ_PHONE_UNIQUE_ID, READ_PHONE_IMEI, READ_PHONE_INCOMING_CALLER,
READ_PHONE_LINE_STATE, READ_PHONE_LOG, etc. Ditto for many other
permissions.

When it comes time to install an application, I can look at what
actually is requested (not just READ_PHONE_STATE), and choose Yes or
No. If I choose Yes, I'd like to take away permissions at a later
time. For example, I might get suspicious and remove READ_PHONE_LOG at
a later time.

For the Enterprise, SE Android/Management Server *should* allow one to
do the same, but from a central console. I should be able to install
(or deny an install), or uninstall, or yank a permission at a later
date.

> But, that's my well known opinion, and as such you may wish to take
> it with a grain of salt. I will be sad to see the Android policy grow
> with the same unbridled exuberance as the Fedora and reference policies.
Not at all.

Unfortunately, I can't comment on policy bloat since Fedora works
great for me out of the box as a single user (no Enterprise). Perhaps
the policy tools are lacking. Again, I've never seen their GUIs, but
the front end should be simple for admins and users who understand
policy (confer: Microsoft, MMC, and Local Security Policy or GPOs).

Jeff

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[Stephen Smalley]

On Mon, 2012-03-05 at 17:02 -0800, Casey Schaufler wrote:
> On 3/4/2012 6:02 PM, Jeffrey Walton wrote:
> > Hi All,
> >
> > Forgive my ignorance here.....
> >
> > I was reading the slides at on SE Android at
> > http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf.
> >
> > I see the slides point out "[Current Android suffers] limited
> > granularity, coarse-grained privilege." But I don't see where SE
> > Android corrected it. For example, it appears READ_PHONE_STATE still
> > encompasses reading a device serial number, IMEI, SIM ID, call state,
> > incoming calling number, etc.
> >
> > Does SE Android remediate the coarse grained permissions?
> >
> > Is an application installation still an "all or nothing" proposition
> > with respect to permissions? For example, can I approve an install and
> > later take away the WRITE_CONTACTS permission?
> 
> I personally applaud the coarser granularity that the Android policy
> has over the Fedora policy. I have long been critical of what I
> consider to be excesses of granularity in SELinux. Do you really want
> to see 900,000 lines of policy for a handset device? And before
> someone starts to claim that the handset system software is somehow
> smaller or less complex than the Fedora distribution I will point to
> Stephen's note about the application enforced policy of Android.
> 
> Fine granularity in access controls are lots of fun for engineers
> and seem like a good idea when you want to turn on a particular
> facility and can't do so because the seemingly unrelated implications
> are too dangerous. But it's a slippery slope, and I seriously doubt
> that anyone would want to truly understand all the relationships
> included in a policy for Android that matches the granularity of the
> policy for Fedora.
> 
> But, that's my well known opinion, and as such you may wish to take
> it with a grain of salt. I will be sad to see the Android policy grow
> with the same unbridled exuberance as the Fedora and reference policies.

Just to be clear, the SE Android (kernel) policy is a small, fixed
policy (with a small set of security goals) that doesn't require any
policy writing by (Android) app developers and that is invisible to
users.  And we intend to keep it that way.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[Stephen Smalley]

On Mon, 2012-03-05 at 21:39 -0500, Jeffrey Walton wrote:
> For what its worth, here's what I envision:
> 
> READ_PHONE_STATE gives the house away (confer:
> http://android-permissions.org/ and the Permission Map). As a matter
> of fact, Goolge forced the permission on *all* apps, whetehr it was
> needed or not (confer:
> http://stackoverflow.com/questions/1747178/android-permissions-phone-calls-read-phone-state-and-identity).
> 
> I want finer permissions than READ_PHONE_STATE. Perhaps
> READ_PHONE_UNIQUE_ID, READ_PHONE_IMEI, READ_PHONE_INCOMING_CALLER,
> READ_PHONE_LINE_STATE, READ_PHONE_LOG, etc. Ditto for many other
> permissions.

While SE Android may ultimately support finer grained permissions for
the application layer access controls, that isn't what we consider to be
the largest issue for the existing Android security model and thus is
not our first priority.  Privilege escalation via confused deputy and
collusion attacks and controlled sharing are the more significant
concerns.  "Towards Taming Privilege Escalation Attacks on Android" from
NDSS 2012 and "Permission Re-Delegation: Attacks and Defenses" from
Usenix Security 2011 are good background on the problems and some
previously proposed solutions.
 
> When it comes time to install an application, I can look at what
> actually is requested (not just READ_PHONE_STATE), and choose Yes or
> No. If I choose Yes, I'd like to take away permissions at a later
> time. For example, I might get suspicious and remove READ_PHONE_LOG at
> a later time.
> 
> For the Enterprise, SE Android/Management Server *should* allow one to
> do the same, but from a central console. I should be able to install
> (or deny an install), or uninstall, or yank a permission at a later
> date.

Permission revocation is already fairly easily supported on existing
Android (and I think supported in some custom builds like CyanogenMod).
But it doesn't address the issues above.

> > But, that's my well known opinion, and as such you may wish to take
> > it with a grain of salt. I will be sad to see the Android policy grow
> > with the same unbridled exuberance as the Fedora and reference policies.
> Not at all.
> 
> Unfortunately, I can't comment on policy bloat since Fedora works
> great for me out of the box as a single user (no Enterprise). Perhaps
> the policy tools are lacking. Again, I've never seen their GUIs, but
> the front end should be simple for admins and users who understand
> policy (confer: Microsoft, MMC, and Local Security Policy or GPOs).

Since we are focused on a limited set of security goals at the kernel
layer for SE Android, and since Android provides a much more constrained
environment for apps than a general purpose Linux distribution, it is
significantly easier to keep the SE Android kernel policy small and
manageable.

To the extent that we keep our focus on mitigating privilege escalation
attacks and controlled sharing for the application layer access
controls, I think we'll also be able to keep the application layer
policy small and manageable.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SE Android and Finer Grained Permissions

[coderman]

On Tue, Mar 6, 2012 at 6:53 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>...
> Just to be clear, the SE Android (kernel) policy is a small, fixed
> policy (with a small set of security goals) that doesn't require any
> policy writing by (Android) app developers and that is invisible to
> users.  And we intend to keep it that way.

can we get XenARM policy enforcement next?  like Qubes+NetTop for mobiles...

</dreamin'>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.