- Putting Android in Its Place
- The Android Service Model
- Exploring the Source
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Android Service Model
A second, side-on view of the Android system gives a more functional perspective. Shown in Figure 3.2, it illustrates the basic structure of Android’s service model.
)
Figure 3.2 The Android System Model
This diagram is key. It illustrates two applications in two separate processes, one on the right and one on the left. The application in the process on the left side of the diagram needs access to the scarce resource at the bottom of the diagram. The arrow from the application to the scarce resource represents its request.
In the diagram the scarce resource is shown as hardware because it often is. Examples of scarce hardware resources might include a phone’s screen, status lights, or a buzzer. Allowing all applications unrestricted access to these things wouldn’t make sense. At best, applications would have to coordinate access among themselves. At worst, a malicious application could make a device unusable by seizing one or more of the essential resources and refusing to release them.
Hardware resources, of course, are not the only things that can be scarce or that need protection. A list of accounts or a database of acquaintances might require similar protection. Android uses the same mechanism to protect non-hardware resources.
In Figure 3.2, the arrow illustrating the application’s intended request for the scarce resource is marked with an “X.” The “X” indicates that application is blocked by the system from making the request directly.
The portal through which an application interacts with hardware—its driver—is almost certainly catalogued as a file in the /dev directory. Recall that as the creator of the file system abstraction, the kernel is able to represent nearly anything as a file. The driver is a special kind of file but still a file. To interact with the resource directly, the application must open the driver file and read and write from it.
Like all files in the Linux file system, the driver file is catalogued with permissions. These permissions determine which processes the kernel will allow to open the file.
Listing 3.1 shows excerpts from the listing of the contents of the /dev directory from a typical Android device. Most of these files are drivers for one device or another. In most cases, the file’s permissions (the first column) limit access to the file’s owner (second column) or owning group (third column). Only a couple of the files in this example allow unrestricted access (crw-rw-rw).
The others are accessible only by processes with specific UIDs.
Listing 3.1 Files in /dev
crw------- root root 233, 0 1970-07-29 16:48 adsprpc-smd crw-rw-r-- system radio 10, 56 1970-07-29 16:48 alarm ... crw-rw---- system audio 10, 40 1970-07-29 16:48 audio_slimslave crw-rw---- nfc nfc 10, 70 1970-07-29 16:48 bcm2079x-i2c crw-rw-rw- root root 10, 62 1970-07-29 16:48 binder crw-r----- radio radio 230, 0 1970-07-29 16:48 hsicctl0 crw-r----- radio radio 230, 1 1970-07-29 16:48 hsicctl1 crw-r----- radio radio 230, 10 1970-07-29 16:48 hsicctl10 ... cr--r----- root system 10, 183 1970-07-29 16:48 hw_random crw------- root root 89, 0 1970-07-29 16:48 i2c-0 ... crw-rw---- system camera 239, 0 1970-07-29 16:48 jpeg0 ... crw-rw---- system camera 251, 0 1970-07-29 16:48 media0 ... crw-rw---- root mtp 10, 43 1970-07-29 16:48 mtp_usb ... crw-rw---- radio vpn 108, 0 1970-07-29 16:48 ppp ... crw-rw---- system drmrpc 244, 0 1970-07-29 16:48 qseecom crw------- root root 10, 92 1970-07-29 16:48 ramdump_adsp ... crw------- root root 232, 3 1970-07-29 16:48 smd3 crw------- root root 232, 36 1970-07-29 16:48 smd36 crw-rw---- system system 232, 4 1970-07-29 16:48 smd4 crw-rw---- system system 232, 5 1970-07-29 16:48 smd5 crw-rw---- system system 232, 6 1970-07-29 16:48 smd6 crw-rw---- bluetooth bluetooth 232, 7 1970-07-29 16:48 smd7 crw------- root root 232, 8 1970-07-29 16:48 smd8 crw-r----- radio radio 231, 25 1970-07-29 16:48 smd_cxm_qmi crw-rw---- bluetooth net_bt_stack 248, 0 2017-01-22 12:16 ttyHS0 crw------- media media 248, 3 2017-01-22 12:16 ttyHS3 crw------- root root 247, 0 1970-07-29 16:48 ttyHSL0 crw-rw---- system vpn 10, 200 1970-07-29 16:48 tun crw-rw---- system net_bt_stack 10, 239 1970-07-29 16:48 uhid ... crw-rw-rw- root root 1, 9 1970-07-29 16:48 urandom crw-rw---- root usb 10, 41 1970-07-29 16:48 usb_accessory
When Linux was first developed in the 1990s, it was designed for computers that were shared by many users. At that time, security in an operating system meant, exactly, protecting users of the same computer from each other. Although attacks from across a network were not unknown, it was far more likely that one of the users of a system would compromise another’s resources on a single system than it was that an attack would originate externally. Over years of use, the ability of the Linux system to protect individual user accounts from one another has been tested, retested, and tested again. It is quite secure.
The permissions system is what prevents the request for the scarce resource shown in Figure 3.2
from succeeding. The application’s process is not running with the user and group IDs that protect the resource and, therefore, the application does not have read or write permission on the driver. It does not have any way to obtain direct access to the resource.
Starting with KitKat, Android included an adaptation of SE Linux that further enhanced access controls. The original discretionary access control (DAC) model of permissions was not enough to prevent a system from being compromised. For example, using only DAC, a highly privileged system service (such as init), 43if compromised, might allow unfettered access to the system. SE Linux for Android introduced mandatory access control (MAC). It allows each running process to be further constrained from a security standpoint. All applications, including system processes, are assigned SE context that is enforced by the kernel. This limits the damage any one process can do, if compromised.
As Chapter 5 will demonstrate, writing and extending SE policies is a non-trivial task. Unless absolutely necessary, not altering the SE policies that are provided in the AOSP tree is best because they are CDD/CTS compliant. This is particularly important if the device is to be certified as an Android device.
The series of unblocked arrows in Figure 3.2 show how Android applications actually do get access to scarce resources when they need them. Instead of requesting the access directly, they use an interprocess communication (IPC) mechanism, Binder, to make a request to a system service. Normally, the IPC request is completely hidden from the caller because it is wrapped in in the Android API libraries. The client app sees only a call to a local method.
When the client app wants to obtain access to a scarce resource, it simply calls one of the methods in the Android API. The method call actually initiates an IPC conversation with Android service applications in one or more remote processes. These service processes, unlike the client, have the necessary security privileges that do permit them to access the scarce resource. The service can coordinate the requests as appropriate and manage access and control client use of the resource. Services provide fine-grained control over application access to the scarce resources they manage by declaring permissions. A permission is nothing more than a unique string that is recognized by the Android system. Android strictly manages permissions: Applications that want to use them must declare their intentions in their manifests and must get explicit approval from the application user before the permissions are granted. When an application requests access to a scarce resource from a service, the service can provide access in the firm knowledge that the application is acting on behalf of an informed user.
This mechanism, access to resources through a proxy service, is the key to hardware access in Android.