[Dailydave] Android Attacks Slides
noloader at gmail.com
Tue Apr 3 21:25:01 EDT 2012
Hey Jim -
Good to see you out and about.
On Tue, Apr 3, 2012 at 11:26 AM, James Manico <jim at manico.net> 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,"
The folks at the NSA also pointed out coarse grained permissions in
their slides introducing SE Android
Its too bad the remediation was not incorporated in the project (I
just about begged for it)
Even marketing and media managers know there is a problem with
permission granularity: "Company at centre of Android apps scare
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).
> On Apr 3, 2012, at 11:17 AM, Tim <tvidas at gmail.com> 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.
>> On Fri, Mar 30, 2012 at 5:50 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> Hi Guys,
>>> Android Attacks (Bas Alberts/Massimiliano Oldani),
>>> 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,"
>>> 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,"
More information about the Dailydave