From: Stephen Smalley <sds@tycho.nsa.gov>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: noloader@gmail.com, SE Linux <SELinux@tycho.nsa.gov>
Subject: Re: SE Android and Finer Grained Permissions
Date: Tue, 06 Mar 2012 09:53:09 -0500 [thread overview]
Message-ID: <1331045589.26027.44.camel@moss-pluto> (raw)
In-Reply-To: <4F556212.50303@schaufler-ca.com>
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.
next prev parent reply other threads:[~2012-03-06 14:53 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
2012-03-06 2:39 ` Jeffrey Walton
2012-03-06 15:08 ` Stephen Smalley
2012-03-06 14:53 ` Stephen Smalley [this message]
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=1331045589.26027.44.camel@moss-pluto \
--to=sds@tycho.nsa.gov \
--cc=SELinux@tycho.nsa.gov \
--cc=casey@schaufler-ca.com \
--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.