All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: noloader@gmail.com
Cc: SE Linux <SELinux@tycho.nsa.gov>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: SE Android and Finer Grained Permissions
Date: Mon, 05 Mar 2012 17:02:10 -0800	[thread overview]
Message-ID: <4F556212.50303@schaufler-ca.com> (raw)
In-Reply-To: <CAH8yC8kE6fEGijSyjz4_VrqoogbrqLAsHwCXsRQH3qd52e=kVw@mail.gmail.com>

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.

  parent reply	other threads:[~2012-03-06  1:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05  2:02 SE Android and Finer Grained Permissions Jeffrey Walton
2012-03-05 15:09 ` James Carter
2012-03-05 19:44   ` Stephen Smalley
2012-03-06  1:02 ` Casey Schaufler [this message]
2012-03-06  2:39   ` Jeffrey Walton
2012-03-06 15:08     ` Stephen Smalley
2012-03-06 14:53   ` Stephen Smalley
2012-03-11  5:55     ` coderman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F556212.50303@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=SELinux@tycho.nsa.gov \
    --cc=noloader@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.