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.
You must accept them all or bail; and for this I feel the model is a fail. -- Jim Manico VP, Security Architecture WhiteHat Security (808) 652-3805 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. >> >> Jeff >> _______________________________________________ >> Dailydave mailing list >> [email protected] >> https://lists.immunityinc.com/mailman/listinfo/dailydave > _______________________________________________ > Dailydave mailing list > [email protected] > https://lists.immunityinc.com/mailman/listinfo/dailydave _______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
