[Dailydave] Android Attacks Slides

[Tim]

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 <noloader at gmail.com> 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
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave