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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
