Hey Jim - Good to see you out and about.
On Tue, Apr 3, 2012 at 11:26 AM, James Manico <[email protected]> wrote: > Even though the Android permission model may be granular, given your > perspective, Android users do not have the option of •accepting• > permissions on a granular basis. Take a look at PHONE_READ_STATE and see the the bug report "Android Permission: 'Phone Calls' Permission is Overly Permissive," http://code.google.com/p/android/issues/detail?id=24104. The folks at the NSA also pointed out coarse grained permissions in their slides introducing SE Android (http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf). Its too bad the remediation was not incorporated in the project (I just about begged for it) (http://www.mail-archive.com/[email protected]/msg17266.html). Even marketing and media managers know there is a problem with permission granularity: "Company at centre of Android apps scare responds," http://www.cbronline.com/blogs/cbr-rolling-blog/company-at-centre-of-android-apps-scare-responds-080312. At least Android fixed the description (???). It used to include "and the like" (http://code.google.com/p/android/issues/detail?id=24103): Allows the application to access the phone features of the device. An application with this permission can determine the phone number and serial number of this phone, whether a call is active, the number that call is connected to and the like. > You must accept them all or bail; > and for this I feel the model is a fail. Yes, most definitely. And there is nothing to revoke a permission after installation. But that's a different complaint (err, story). Jeff > On Apr 3, 2012, at 11:17 AM, Tim <[email protected]> wrote: > >> The "fine" vs "coarse" grained is somewhat subjective given the >> various resources available on a device, but level of granularity >> certainly varies across the permissions. One that is often cited as >> too coarse is "INTERNET" where many suggest limiting apps more finely >> to particularly domains or hierarchical models. Text messaging has >> several, more granular permissions dividing access among sending, >> receiving, reading, and writing for each of SMS and MMS (which some >> will argue could be even more granular limiting access to certain >> contacts, country codes, non-premium numbers, etc). >> >> The "borking" you refer to at the end is an interesting problem. >> Originally there were many fewer permissions than there are now, so >> what should happen when a new permission is specified by an app and >> that app is installed on an old device? The older OS doesn't know >> anything about the new permission nor how to enforce it, so a design >> decision was made to silently ignore the permission request. There >> are also odd situations with the UI. For example, when you install >> the app, it will list the permissions that the OS supports, but >> post-install if you inspect the app via the Applications menu in >> Settings it will list the permissions found in the app manifest. So >> in the stackoverflow example you linked, at install time you would not >> see the WRITE_EXTERNAL_STORAGE permission but when inspecting the app >> via Settings on the same device you would (this behavior may vary >> based on API version - I have not checked them all). >> >> Alternate design decisions could have been made, for example the >> installer could refuse to install apps that specify unknown >> permissions in the manifest. In this case developers would have to >> support an app for old devices that are unaware of >> WRITE_EXTERNAL_STORAGE (a request for this permission is not needed >> anyway because the OS cannot enforce it), and also a nearly identical >> app that does specify the permission for newer devices. For about 1 >> year now, the Android Market (now Google Play) has supported this >> split-distribution model where the appropriate variant of the app is >> delivered to a device - but it is still fairly annoying for the >> developer. Many apps are poorly written with manifests that specify >> the same permission multiple times, misspell permissions or even >> specify permissions that have never existed. An installer that >> doesn't install apps with unknown permissions would at least force >> some of these practices to clean up. >> >> The situation is, of course, worsened by the lagging / nonexistent >> Android OS updates, the relatively short supported lifespan of >> devices, and alternative app sources. >> >> -tim >> >> On Fri, Mar 30, 2012 at 5:50 PM, Jeffrey Walton <[email protected]> wrote: >>> Hi Guys, >>> >>> Android Attacks (Bas Alberts/Massimiliano Oldani), >>> http://www.immunityinc.com/infiltrate/2011/presentations/Android_Attacks.pdf. >>> >>> Perhaps I'm reading Slide 15 wrong: >>> >>> Fine grained Permission/Capability model >>> ● Per installed Application (Manifest) >>> ● Per URI (Intent permission flags) >>> >>> I believe Android lacks Fine Grained permissions: >>> >>> Felt, Adrienne Porte; Chin, Erika; Hanna, Steve; Song, Dawn; Wagner, >>> David. "Android Permissions Demystified," >>> http://www.cs.berkeley.edu/~afelt/android_permissions.pdf. >>> Jeon, Jinseong; Micinski, Kristopher K.; Vaughan, Jeffrey A.; Reddy, >>> Nikhilesh; Zhu, Yixin; Foster, Jeffrey S.; Millstein, Todd." Dr. >>> Android and Mr. Hide: Fine-grained security policies on unmodified >>> Android," http://www.cs.umd.edu/~jfoster/papers/acplib.pdf. >>> >>> In fact, the permissions are so coarse grained and borked that Google >>> was giving everone READ_PHONE_STATE whether they wanted it or not (the >>> practice has been changed). And READ_PHONE_STATE includes call >>> status, incoming number, identity iformation such as IMSI, etc. See >>> "Android permissions: Phone Calls: read phone state and identity," >>> http://stackoverflow.com/questions/1747178/android-permissions-phone-calls-read-phone-state-and-identity. _______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
