Screenshots, event injection and "signature" permissions
Adrian Taylor
I believe there are scenarios where third-party applications may
require permissions that are impossible to obtain with the current
Android security model and permissions settings.
Three examples:
* A screenshotting application. That requires READ_FRAME_BUFFER
permission which is 'signature' level.
* Third parties want an automated testing tool. Said tool wishes to
interact with UI widgets, therefore injecting key and touch events.
That needs INJECT_EVENTS permission; again, 'signature' level.
* VNC server wishes to allow users (and their IT help desks etc.) to
remotely control the device. This needs both.
All three of these are valid third-party software products which are
possible on the other major mobile device platforms. Yet they're not
possible on Android.
Of course, they also happen to allow complete control of the device. So
Dianne Hackborn and Mathias Agopian say 'no' to switching these
permissions simply to 'dangerous' level.
Fair enough. But how can we improve the Android platform to allow the
granting of these 'scary' permissions?
To kick off the discussion, Dianne Hackborn says[1]:
> ... doing something just because Symbian, Blackberry, or Windows
> Mobile does it is not necessarily the right thing to do. :)
> Especially when we look at security, there are some big differences
> -- both Symbian and Blackberry require that apps be signed with
> trusted certificates for the apps to run (and these certs can limit
> what the apps can do), which is a very different model than the more
> open one we have adopted for Android.
>
> Because of our open model, it is a non-starter to just make these
> permissions at the same level as, say, reading your contact data. By
> and large, what we have here are things that "normal" applications
> should simply never do, and allowing them to be used has extremely
> serious security repercussions in the system:
>
> - The inject events permission effectively grants an application
> EVERY possible permission, because it can drive the UI and do
> anything the user can do.
> - The screen shot permission allows the application, any time the
> user is operating the device, to monitor them and do very dangerous
> things like collect every password they type in web pages and
> elsewhere.
>
> One could imagine creating new kinds of APIs for these things that
> try to limit the scope of the problem (for example not accepting
> input into any system settings panels, not getting screenshots for
> anywhere there may be a password), but that will simply result in
> something that is not useful for a [VNC server] anyway, so I don't
> think worth discussing here.
>
> At the end of the day, what you are wanting to do is be able to
> create a whole new class of application that essentially operates as
> a proxy for the user. We currently don't have a mechanism or design
> for this in our security model. We can talk about what we might add
> to allow that (I do agree eventually we want to allow such
> functionality), but let's do that on the groups. A code review is
> not the place for this discussion, and this level of design requires
> security engineers and UI designers to be involved.
So here we are :-)
Proposals:
* Simply provide much scarier warnings for the user when an application
asks to use these permissions.
* Have an extra level of permission somewhere between 'dangerous'
and 'signature'. Maybe 'terrifying'? Disallow self-signing for apps
wishing to use those permissions. Insist on a signature trail in
the certificates which eventually leads to a reputable
certification company.
* Upon installation of such applications (or even upon execution)
the signature of the application is checked against a central
Android server to see if the application has been 'revoked' for
being naughty. Obviously this is shutting the stable door after the
horse has bolted.
* Insist that such applications are signed by some central signing
program of the Android project. Which doesn't exist. Possibly
involving some testing program, or even auditing of the source
code. Shudder.
* Simply decide to restrict this functionality forever to software
within the Android platform itself. This goes against Android's
'open' culture where you can even replace things like the Home
Screen, so it would be a shame.
All of these proposals are, of course, unappealing, which is why I'd
like to start a discussion here.
For the record - I dislike the centralised signing programmes of
certain other platforms - and I really like Android's open approach.
But I think the above use-cases are realistic. Even discounting the
VNC use-case in which I'm particularly interested, I'm sure you'll
get pressure from journalists (via OEMs) to allow screenshotting
applications sometime soon!
Thanks in advance for any suggestions!
Adrian
[1] http://review.source.android.com/Gerrit#change,8866
Dianne, I hope you didn't mind me quoting you since it was public
anyway and is a useful start to the discussion.
Mike Hearn
> possible on the other major mobile device platforms. Yet they're not
> possible on Android.
(as any app can run "su" to get root, it's effectively disabled by
default).
For these use cases specifically:
1) Screenshotting could just be a built-in app or hidden platform
feature (special key combo?). Built-in apps can use permissions that
regular apps cannot.
2) Automated testing is something developers want to do, eg, on the
Android Developer Phone or emulator
3) VNC, I am really sceptical the target audience for Android phones
would find this useful. But you are right that it's not possible
today. For the IT help desk scenario specifically, I think Android
will need a more fully thought out solution for letting corp IT
departments control the device remotely. Perhaps some way of giving
third parties root on a device such that they can run arbitrary
commands on them. I'm not sure how this would interact with operators
needs here, but presumably large corp deployments can negotiate those
out.
> * Simply provide much scarier warnings for the user when an application
> asks to use these permissions.
us to read, they will show many users don't read or fully understand
the permissions screen today. So I think this one is out.
> * Upon installation of such applications (or even upon execution)
> the signature of the application is checked
out.
> * Simply decide to restrict this functionality forever to software
> within the Android platform itself.
is probably the best option. There's a difference between being open
source and being insecure - the source would still be available, the
permissions just wouldn't be available to installable apps, unless you
have root on the phone.
thanks -mike
Adrian Taylor
Thanks very much for your comments.
On Mon, 2009-02-16 at 05:15 -0800, Mike Hearn wrote:
> 1) Screenshotting could just be a built-in app or hidden platform
> feature (special key combo?). Built-in apps can use permissions that
> regular apps cannot
Yes; this would indeed mean that the *time* of screen capture is
entirely under the control of the user. The data would still be
accessible to other applications, of course, assuming it was saved onto
the SD card or similar.
If our only objective is to ensure the user has control over the exact
time that a screenshot is taken, perhaps another solution would be to
ask for 'take screenshot' permissions when the screenshot activity
appears on the screen or even when the API was called (instead of at
install-time). Popping up a permissions box at API-call-time is no good
for VNC, though.
I still don't like the idea that useful permissions are only accessible
to built-in applications. See discussion later.
> 2) Automated testing is something developers want to do, eg, on the
> Android Developer Phone or emulator
I respectfully disagree. I think many testing teams would say there's
not much point doing testing unless it's on a device that is pretty much
identical to the finished gadget which end-users will have. Enabling
root or using the emulator would make the testing less useful. This is
arguably especially true of automated testing which may be done across a
'farm' of devices on which a given application is to be deployed.
> 3) VNC, I am really sceptical the target audience for Android phones
> would find this useful.
I was, too! When I came to work here and they said they wanted a VNC
*server* I thought they must have got mixed up. But apparently we're
both wrong. :-)
> But you are right that it's not possible
> today. For the IT help desk scenario specifically, I think Android
> will need a more fully thought out solution for letting corp IT
> departments control the device remotely. Perhaps some way of giving
> third parties root on a device such that they can run arbitrary
> commands on them.
Giving third-parties root sounds so much worse than selectively opening
up some (admittedly powerful) permissions where the user will at least
be told what's going on.
Now onto discussion of a few of the possible solutions:
> > * Simply provide much scarier warnings for the user when an application
> > asks to use these permissions.
>
> I am guessing that when usability studies of Android are published for
> us to read, they will show many users don't read or fully understand
> the permissions screen today. So I think this one is out.
Sadly, I agree with you. Although perhaps there's scope for presenting
really dangerous permissions checks at runtime rather than install-time?
(The devil would be in the detail of course, and it might not help that
much anyway with the user's understanding).
> > * Simply decide to restrict this functionality forever to software
> > within the Android platform itself.
>
> A few apps cannot be replaced by users already, eg the dialer, so this
> is probably the best option. There's a difference between being open
> source and being insecure - the source would still be available, the
> permissions just wouldn't be available to installable apps, unless you
> have root on the phone.
I know - and I appreciate the different types of openness in the Android
project. But the "replaceability" openness is arguably more unique these
days than the "open source" type of openness, which certain other
platforms seem to be doing too these days :-) Being able to replace
things like the Home Screen is probably also more important to the
end-user than the openness of the source code.
To be truly able to replace any useful app within an Android device, I
think no permissions should be 'signature[OrSystem]' except those which
absolutely, definitively, could have no third-party usefulness.
If you'd argue that full replaceability isn't critical, I'd reply by
saying that OEMs and netops are bound to "inadvertently" use
'signature[OrSystem]' permissions in their home screens, and then users
won't even be able to replace their home screens (with equivalents).
Thanks again for your comments, but I remain convinced that excluding
all the 'signature' permissions from use by third-party applications
can't last forever. I'd love to hear any other suggestions about how
there could be some compromise means to open them up. Does it involve
signing and testing programmes or is there some better way?
Thanks again,
Adrian
Mike Hearn
intent, so users and apps can trigger "take screenshot" functionality,
but that screenshot is then saved to internal storage, emailed to
somebody, sent via bluetooth etc depending on the choice of the user.
Letting users take screenshots is totally different to letting apps
take screenshots.
Re: testing, maybe apps signed with the same keys could be allowed to
send each other input events and screenshot each other? This way you
can build a separate testing system that "scripts" your app, but it's
not insecure. The disadvantage is you can't test across invocations of
other apps, but it would suffice for many apps. It wouldn't need to be
a permission then either, it'd just be something they could do.
> I was, too! When I came to work here and they said they wanted a VNC
> *server* I thought they must have got mixed up. But apparently we're
> both wrong. :-)
> Sadly, I agree with you. Although perhaps there's scope for presenting
> really dangerous permissions checks at runtime rather than install-time?
wouldn't lead to a J2ME type experience, but it's not my call to
make.
I think you have to assume that a high percentage of users won't read
any dialogs that pop up on the screen though, but rather, just hit
whatever button they see first. This is certainly true of desktop
software. At least the permissions window is expected and always
appears at a consistent time (and whacking through it doesn't get you
what you want any quicker anyway, as time taken to read it is much
lower than download times).
> Being able to replace
> things like the Home Screen is probably also more important to the
> end-user than the openness of the source code.
going to be a compromise. For instance the reason the Dialer can't be
replaced is something to do with emergency numbers (??) and the reason
the lock screen can't be replaced is a lock screen with buggy power
manager interaction could brick the device (ie, prevent you switching
it on).
At any rate, I don't have anything more to say. Somebody with more
authority than me would need to chime in.
Cédric Berger
>
> I think you have to assume that a high percentage of users won't read
> any dialogs that pop up on the screen though, but rather, just hit
> whatever button they see first. This is certainly true of desktop
> software. At least the permissions window is expected and always
> appears at a consistent time (and whacking through it doesn't get you
> what you want any quicker anyway, as time taken to read it is much
> lower than download times).
>
Yes may be true for desktop software also. But not sure the solution
would be microsoft to prevent absolutly all applications from
accessing any Windows API judged potentially dangerous !
Mike Hearn
> would be microsoft to prevent absolutly all applications from
> accessing any Windows API judged potentially dangerous !
largely because apps have unrestricted access to debug APIs and other
very powerful things that let them modify the system in arbitrary
ways. Android is designed to try and prevent that. So yes in fact that
would be the solution for Microsoft (except it's too late for Windows).