Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Android System's use of Binder Tokens

I am reading about use of Binder tokens inside Android System at this blog post. I saw the example related to wakelocks where the token is used to identify subsequent requests from same application.

I want to ask why in the Android system the UID of the calling application is not enough to track subsequent requests from the application ? Is there any need Binder tokens fulfill that UID cannot in terms of identifying an application?

like image 810
Jake Avatar asked Sep 14 '15 23:09

Jake


1 Answers

A Binder token does not identify an application in the way that the uid does. A token is a capability or ticket, which means that possession is what counts. In other words, with a binder token, it doesn't matter who or what you are, but only whether you possess the token. This last part is key: in the Android Framework, there are many objects that need to be differentiated for security reasons, but they either all have the same uid (e.g., objects in the system_server process space) and/or the uid doesn't identify the true subject (e.g., code running on the local side of Binder RPC).

This difference with respect to uid enables functionality that wouldn't be easily achievable, or even possible with uid. A good example is in the blog post you referenced:

Applications can ask the InputMethodManager to hide the soft keyboard by calling the hideSoftInputFromWindow(IBinder windowToken, int flags) method, but must provide a window token as part of the request. If the token doesn't match the window token belonging to the window currently accepting input, the InputMethodManager will reject the request. This makes it impossible for malicious applications to force-close a soft keyboard opened by another application.

The main reason for using tokens here is that a window object isn't something that has a uid. Sure, it is part of some process somewhere that has a uid, but whatever that uid is, it's not the uid of the application trying to hide the soft keyboard. Thus, the only way ensure that the requester own the window currently accepting input is to force the application to supply the token it was given by WindowManager when the window was first created.

like image 73
Paul Ratazzi Avatar answered Sep 27 '22 20:09

Paul Ratazzi