model is not violated during these processes. Moreover, it also acts as a policy decision point. The methods of this service (as we will show later) are the last elements in the chain of the permission checks. We will not consider the operation of PackageManagerService here. However, the interested reader may refer to [15, 19] to get some more details how the installation of applications is performed.
PackageManagerService stores all information related to permissions of third-party applications in the /data/system/packages.xml [7]. This file is used as a persistent storage between the restarts of the system. However, at runtime all information about permissions is preserved in RAM allowing to increase the responsiveness of the system. This information is collected during the boot using the data stored in the packages.xml file for third-party applications and through parsing system apps.
4.3
Permission Enforcement on the Application Frame-
work level
To understand how Android enforces permissions on the Application Frame- work level, for instance, let consider the Vibrator Service. In Listing 4.3 in Line 6 an example how the Vibrator Service protects its method vibrate is shown. In this line the check is performed if a calling component is as- signed with the label android.permission.VIBRATE defined by the con- stant android.Manifest.permission.VIBRATE. Android provides several methods to check if a sender (or service consumer) has been assigned with a permission. In our case, these facilities are represented by the method checkCallingOrSelfPermission. Additionally to this method, there are also a number of other methods that can be used to check the permissions of the service caller.
The implementation of the method checkCallingOrSelfPermission is shown in Listing 4.4. In Line 24 the method checkPermission is called. It takes the uid and the pid as parameters that are provided by the Binder
CHAPTER 4. ANDROID SECURITY ON THE FRAMEWORK LEVEL 1 p u b l i c c l a s s V i b r a t o r S e r v i c e e x t e n d s I V i b r a t o r S e r v i c e . Stub 2 i m p l e m e n t s InputManager . I n p u t D e v i c e L i s t e n e r { 3 . . . 4 p u b l i c v o i d v i b r a t e (l o n g m i l l i s e c o n d s , I B i n d e r t o k e n ) { 5 i f ( mContext . c h e c k C a l l i n g O r S e l f P e r m i s s i o n ( a n d r o i d . M a n i f e s t . p e r m i s s i o n . VIBRATE)
6 != PackageManager . PERMISSION GRANTED) {
7 throw new S e c u r i t y E x c e p t i o n (” R e q u i r e s VIBRATE p e r m i s s i o n ”) ;
8 }
9 . . .
10 }
11 . . .
12 }
Listing 4.3: The check of a permission
framework.
In Line 11, the check is redirected to the ActivityManagerService class
that in turn performs the actual check in the method checkComponentPermission of the ActivityManager component. The code of this method is presented
in Listing 4.5. In Line 4 it checks if the caller UID belongs to the privileged ones. The components with the root and system UIDs are granted by the system with all permissions.
In Line 26 in Listing 4.5 the permission check is redirected to Package Manager that forwards it to PackageManagerService. As we explained before, this service knows what permissions are assigned to Android pack- ages. The PackageManagerService method, which performs the permis- sion check, is presented in Listing 4.6. In Line 7 the exact check is per- formed if a permission is granted to the Android app defined by its UID.
1 c l a s s C o n t e x t I m p l e x t e n d s C o n t e x t { 2 . . . 3 @Override 4 p u b l i c i n t c h e c k P e r m i s s i o n ( S t r i n g p e r m i s s i o n , i n t pid , i n t u i d ) { 5 i f ( p e r m i s s i o n == n u l l) { 6 throw new I l l e g a l A r g u m e n t E x c e p t i o n (” p e r m i s s i o n i s n u l l ”) ; 7 } 8 9 t r y { 10 r e t u r n A c t i v i t y M a n a g e r N a t i v e . g e t D e f a u l t ( ) . c h e c k P e r m i s s i o n ( 11 p e r m i s s i o n , pid , u i d ) ; 12 } c a t c h ( RemoteException e ) {
13 r e t u r n PackageManager . PERMISSION DENIED ;
14 } 15 } 16 17 @Override 18 p u b l i c i n t c h e c k C a l l i n g O r S e l f P e r m i s s i o n ( S t r i n g p e r m i s s i o n ) { 19 i f ( p e r m i s s i o n == n u l l) { 20 throw new I l l e g a l A r g u m e n t E x c e p t i o n (” p e r m i s s i o n i s n u l l ”) ; 21 } 22 23 r e t u r n c h e c k P e r m i s s i o n ( p e r m i s s i o n , B i n d e r . g e t C a l l i n g P i d ( ) , 24 B i n d e r . g e t C a l l i n g U i d ( ) ) ; 25 } 26 . . . 27 }
1 p u b l i c s t a t i c i n t c h e c k C o m p o n e n t P e r m i s s i o n ( S t r i n g p e r m i s s i o n , i n t uid ,
2 i n t owningUid , b o o l e a n e x p o r t e d ) {
3 // Root , s y s t e m s e r v e r g e t t o do e v e r y t h i n g . 4 i f ( u i d == 0 | | u i d == P r o c e s s . SYSTEM UID) {
5 r e t u r n PackageManager . PERMISSION GRANTED ;
6 }
7 // I s o l a t e d p r o c e s s e s don ’ t g e t any p e r m i s s i o n s . 8 i f ( U s e r I d . i s I s o l a t e d ( u i d ) ) {
9 r e t u r n PackageManager . PERMISSION DENIED ;
10 }
11 // I f t h e r e i s a u i d t h a t owns w h a t e v e r i s b e i n g a c c e s s e d , i t h a s 12 // b l a n k e t a c c e s s t o i t r e g a r d l e s s o f t h e p e r m i s s i o n s i t r e q u i r e s . 13 i f ( owningUid >= 0 && U s e r I d . isSameApp ( uid , owningUid ) ) {
14 r e t u r n PackageManager . PERMISSION GRANTED ;
15 }
16 // I f t h e t a r g e t i s n o t e x p o r t e d , t h e n nobody e l s e can g e t t o i t . 17 i f ( ! e x p o r t e d ) {
18 S l o g . w(TAG, ” P e r m i s s i o n d e n i e d : c h e c k C o m p o n e n t P e r m i s s i o n ( ) owningUid=” + owningUid ) ;
19 r e t u r n PackageManager . PERMISSION DENIED ; 20 }
21 i f ( p e r m i s s i o n == n u l l) {
22 r e t u r n PackageManager . PERMISSION GRANTED ;
23 } 24 t r y {
25 r e t u r n AppGlobals . getPackageManager ( )
26 . c h e c k U i d P e r m i s s i o n ( p e r m i s s i o n , u i d ) ;
27 } c a t c h ( RemoteException e ) {
28 // S h o u l d n e v e r happen , but i f i t d o e s . . . deny ! 29 S l o g . e (TAG, ” PackageManager i s dead ? ! ? ”, e ) ;
30 }
31 r e t u r n PackageManager . PERMISSION DENIED ;
32 }
1 p u b l i c i n t c h e c k U i d P e r m i s s i o n ( S t r i n g permName , i n t u i d ) { 2 f i n a l b o o l e a n e n f o r c e d D e f a u l t = i s P e r m i s s i o n E n f o r c e d D e f a u l t ( permName ) ; 3 s y n c h r o n i z e d ( mPackages ) { 4 O b j e c t o b j = m S e t t i n g s . g e t U s e r I d L P r ( U s e r H a n d l e . getAppId ( u i d ) ) ; 5 i f ( o b j != n u l l) { 6 G r a n t e d P e r m i s s i o n s gp = ( G r a n t e d P e r m i s s i o n s ) o b j ; 7 i f ( gp . g r a n t e d P e r m i s s i o n s . c o n t a i n s ( permName ) ) {
8 r e t u r n PackageManager . PERMISSION GRANTED ;
9 }
10 } e l s e {
11 HashSet<S t r i n g > perms = m S y s t e m P e r m i s s i o n s . g e t ( u i d ) ;
12 i f ( perms != n u l l && perms . c o n t a i n s ( permName ) ) {
13 r e t u r n PackageManager . PERMISSION GRANTED ;
14 }
15 }
16 i f ( ! i s P e r m i s s i o n E n f o r c e d L o c k e d ( permName , e n f o r c e d D e f a u l t ) ) {
17 r e t u r n PackageManager . PERMISSION GRANTED ;
18 }
19 }
20 r e t u r n PackageManager . PERMISSION DENIED ;
Chapter 5
Android Security on the Application
Level
Although in this section we describe the security on the Application level, the actual security enforcement usually happens on lower layers described so far. However, it is easier to explain some security features of Android after introducing the Application level.
5.1
Application Components
Android apps are distributed in the form of Android Package (.apk) files. A package consists of Dalvik executable files, resources files, a manifest file and native libraries, and is signed by the developer of the applications using self-signed certificate.
Each Android application consists of several components of four compo- nent types: Activities, Services, Broadcast Receivers and Content Providers. The separation of an application into the components supports the reuse of application parts between the apps.
Activity . An Activity is an element of user interface. Generally speaking, the activity often represents a screen.
Service . A Service is a background worker in Android. The service can run indefinite time. The most famous example of a service is media
CHAPTER 5. ANDROID SECURITY ON THE APPLICATION LEVEL
player that plays music in the background even if the user leaves the activity that has started this service.
Broadcast receiver . A Broadcast Receiver is a component of an applica- tion that receives broadcast messages and starts a workflow according to the obtained message.
Content provider . A Content Provider is a component that provides an application with abilities to store and retrieve data. It also permits to share a set of data with another application.
So as Android applications consist of different components, there is no central entry point unlike Java programs with the main method. Having no central point, all components (with an exception to broadcast receivers that may also be defined dynamically) need to be declared by the developer of an application in the AndroidManifest.xml file. The separation into com- ponents makes possible to use parts in other applications. For instance, in Listing 5.1 an example of app’s AndroidManifest.xml file is shown. This application consists of one Activity declared in Line 21. Other applications may call this activity integrating the functionality of this component into their apps.
Android provides a variety of methods to invoke the components of ap- plications. A new Activity is started by using the methods startActivity and startActivityForResult. Services are started through the method startService. In this case, called service invokes its method onStart. When a developer is going to establish a connection between a compo- nent and a service she invokes the bindService method and the onBind method is invoked in the called service. Broadcast receivers are started when an app or system component send special messages using the meth- ods sendBroadcast, sendOrderedBroadcast and sendStickyBroadcast. Content providers are invoked by the requests from content resolvers. All other component types are activated through Intents. Intents is a special mean of communication in Android based on the Binder framework.
5.1. APPLICATION COMPONENTS
1 <?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=” u t f −8”?>
2 <m a n i f e s t x m l n s : a n d r o i d=” h t t p : // schemas . a n d r o i d . com/ apk / r e s / a n d r o i d ” 3 p a c k a g e=”com . t e s t p a c k a g e . t e s t a p p ” 4 a n d r o i d : v e r s i o n C o d e=” 1 ” 5 a n d r o i d : v e r s i o n N a m e=” 1 . 0 ” 6 a n d r o i d : s h a r e d U s e r I d=”com . t e s t p a c k a g e . s h a r e d u i d ” 7 a n d r o i d : s h a r e d U s e r L a b e l=” @ s t r i n g / s h a r e d U s e r I d ” > 8 9 <u s e s −sdk a n d r o i d : m i n S d k V e r s i o n=” 10 ” /> 10 11 <p e r m i s s i o n a n d r o i d : n a m e=”com . t e s t p a c k a g e . p e r m i s s i o n . m y p e r m i s s i o n ” 12 a n d r o i d : l a b e l=” @ s t r i n g / m y p e r m i s s i o n s t r i n g ” 13 a n d r o i d : d e s c r i p t i o n=” @ s t r i n g / m y p e r m i s s i o n d e s c r s t r i n g ” 14 a n d r o i d : p r o t e c t i o n L e v e l=” d a n g e r o u s ” /> 15 16 <u s e s −p e r m i s s i o n a n d r o i d : n a m e=” a n d r o i d . p e r m i s s i o n . SEND SMS”/> 17 18 < a p p l i c a t i o n 19 a n d r o i d : i c o n=” @drawable / i c l a u n c h e r ” 20 a n d r o i d : l a b e l=” @ s t r i n g / app name ” > 21 < a c t i v i t y a n d r o i d : n a m e=” . T e s t A c t i v i t y ” 22 a n d r o i d : l a b e l=” @ s t r i n g / app name ” 23 a n d r o i d : p e r m i s s i o n=”com . t e s t p a c k a g e . p e r m i s s i o n . m y p e r m i s s i o n ” > 24 <i n t e n t − f i l t e r > 25 <a c t i o n a n d r o i d : n a m e=” a n d r o i d . i n t e n t . a c t i o n . MAIN” /> 26 <c a t e g o r y a n d r o i d : n a m e=” a n d r o i d . i n t e n t . c a t e g o r y .LAUNCHER” /> 27 </ i n t e n t − f i l t e r > 28 <i n t e n t − f i l t e r >
29 <a c t i o n a n d r o i d : n a m e=”com . t e s t p a c k a g e . t e s t a p p . MY ACTION” />
30 <c a t e g o r y a n d r o i d : n a m e=” a n d r o i d . i n t e n t . c a t e g o r y .DEFAULT” />
31 </ i n t e n t − f i l t e r >
32 </ a c t i v i t y>
33 </ a p p l i c a t i o n>
34 </ m a n i f e s t>
Listing 5.1: Example of the AndroidManifest.xml file
Intents are passed into the methods that perform component invocation. The called component can be invoked by two different types of intents. To show the differences of these types, let consider an example. For instance, a user wants to choose a picture in an application. The developer of the application can use an Explicit Intent or an Implicit Intent to invoke a component that selects a picture. For the first intent type, the developer realizes picking functionality in the component of his application and calls this component using the Component Name data field of the explicit intent. Of course, the developer can invoke a component of other application, but, in this case, he has to be sure that this application is installed in the system. Generally, from the developer’s point of view, there is no
CHAPTER 5. ANDROID SECURITY ON THE APPLICATION LEVEL
difference between the interactions of components inside one application or among components of different applications. For the second intent type, the developer transfers the right to choose the appropriate component to the operating system. The intent object contains some information in its Action, Data and Category fields. According to this information, using Intent Filters the operating system chooses the proper component that may process the intent. An intent filter defines the ”template” of intents the component can process. Of course, the same application can define an intent filter that will process intents from other component.