An analysis of Android binder mechanism

Binder is an IPC mechanism on Android that is important and difficult to understand. Due to the lack of flexibility and reliability of the standard IPC on Linux, Google has implemented binders based on Openbinder's design and vision.

This article simply introduces its implementation and focuses on binder security-related content. Detailed Binder design and implementation analysis, refer to Appendix 4 article.

First, the Binder implementation

Android Binder consists of 4 components driven by client, Server, Service Manager, and Binder, and is quoted as a network.

In Unix-like systems, processes are independent of each other, and one process cannot access the memory space of another process. The kernel, however, controls all processes so that an interface can be exposed as an IPC. In Binder this interface is the/dev/binder device, which is implemented by the binder kernel driver.

The binder driver is the core of the entire binder architecture, which is implemented by all IPC.

The client and server can be viewed as 2 processes, and its IPC is implemented by the IOCTL of the/dev/binder. From the Android source, you can see that the IOCTL uses the BINDER_WRITE_READ structure to send and receive data.

Where Write_buffer contains the commands to be executed, Read_buffer contains the commands that the user layer needs to execute:

Binder_write implements the IOCTL () operation on the BS->FD:

BS->FD is the file descriptor that opens/dev/binder:

How does the actual data transfer between processes?

The binder driver manages a portion of the address space for each process. The binder-managed memory, which is read-only for the process, is implemented by the kernel module for its write operations. When a process sends a message to another process, the kernel requests a portion of the space in the memory space of the target process, and then copies the data directly from the sending process. It then receives the exact location of the message, which is notified to the receiving process via a short message. Because the message is in the receiver's memory space, the receiver can access the message directly. When this data is no longer needed by the process, it notifies the binder driver to release the memory block.

It can be found that the data has been copied once, so binders are less efficient than shared memory.

Higher-level IPC abstractions in Android, such as intent (a command that carries associated data across process components), Messenger (an object that supports cross-process message communication), ContentProvider (a component that exposes a cross-process data management interface), are based on binder implementations.

Second, Binder security

A simple example showing the binder IPC architecture.

Each implementation of the IBinder interface through the binder framework allows the object to be accessed to be called a Binder object. The call to the Binder object is implemented inside a binder transaction (transaction), which includes a reference to the target object, the ID of the method to execute, and a data buffer.

The binder driver automatically adds the ID (PID) of the calling process and the valid user ID (EUID) to the transacted data. The called process can examine the PID and Euid, and then decide whether to execute the requested method based on the internal implementation logic.

Because the PID and euid are filled in by the kernel, the caller process cannot spoof the identity to get beyond the system's allowed permissions. This is one of the core of the Android security model, and all higher levels of abstraction, such as permissions, are built on top of it. The caller's PID and euid are accessed through the class Android.os.Binder Getcallingpid () and Getcallinguid (), which are part of the Android public API.

Third, Binder tokens

An important property of binder objects is that it has a cross-process, unique identity. So if process a creates a binder object and then passes it to process B, and process B passes it to process C, the call to the 3 processes is handled by the same binder object. In fact, process a directly references binder objects through memory addresses, while processes B and C use a handle to the binder object.

The kernel is responsible for maintaining the mapping between the active binder objects and their handles in other processes. Because a binder identifier is unique and is maintained by the kernel, it is not possible to create a copy of a Binder object or get a reference to a Binder object unless it is handled by the IPC mechanism. The Binder object is therefore unique, non-spoofed, and can be used as a security token.

This also allows Android to use the power-based security model (capability-based).

The power-based security model authorizes the program to access specific resources by giving the program an ability not to forge. In Android, binder objects can represent power.

In this way, binder objects are also called Binder tokens (Binder token). A binder token can be a power or a target resource. A process has a binder token that authorizes the process to have full access control over the binder object, allowing it to perform binder transaction operations on the target object. If the Binder object implements multiple actions (based on the code parameter of the binder transaction, selects the action to be performed), any action can be performed as long as the caller has a reference to the Binder object. If finer-grained access control is required, then each operation needs to implement the necessary permission checks accordingly, which is usually done using the PID and EUID of the caller's process.

As seen above, once the Binder object reference (Binder token) is obtained, full access to the target binder object is obtained, which is dangerous if the binder transaction operation involves sensitive actions.

In Android, a calling process that is normally run under System (UID 10000) or root (uid 0) permissions allows all operations to be performed, while additional permission checks are performed for other processes. Therefore, there are 2 ways to control access to an important binder object: One is to check the caller's identity flag (required by the Binder object itself), by restricting who can get a reference to the Binder object, and the other, before executing the Binder object action.

Binder objects can be implemented with no other functionality and are used only as power. In this mode, multiple collaboration processes can have the same binder object at the same time, and the process as a server (processing a client request) uses a binder token to authenticate its client, just as the Web servers use session cookies.

Iv. Binder Object Access

For security reasons, Android Controls access to binder objects, and the only way to communicate with binder objects is to use references to that object. But many binder objects need to be globally accessible (especially for system services). Distributing all binder objects to each process is impractical, so a mechanism is required to allow the process to proactively discover and obtain references to these binder objects.

Android uses the Servicemanger native daemon to implement this discovery mechanism.

Servicemanger starts before the system service, so the system service starts by passing the service name and a Binder object reference to Servicemanger for registration. Once the registration is successful, any client can obtain its Binder object reference through the service name. However, most system services have additional permission checks, so getting a reference does not automatically ensure access to all of its features.

At the same time, because anyone can access the Binder object reference after registering on Servicemanger, only a subset of the system processes in the whitelist can be registered as system services for security reasons.

The list of registered system services can be viewed through the Service List command, which returns the name of each registered service and the IBinder interface of the implementation.

V. Appendices

Android interprocess communication (IPC) Mechanism Binder Brief introduction and Learning Plan

Android in layman's binder mechanism

Android Bander design and implementation-Design chapter

Android Binder Design and implementation-implementation chapter

An analysis of Android binder mechanism