Writing Allow Rules

When developing new features or hardware integrations in AOSP, you will frequently encounter SELinux access denials. Resolving these denials requires writing allow rules in Type Enforcement (.te) files to explicitly grant the necessary permissions.

allow Rule Syntax: allow domain type:class permission

The fundamental building block of SELinux policy is the allow rule. Its syntax is straightforward:

allow <domain> <type>:<class> { <permissions> };

• domain: The SELinux context of the subject (process) requesting access.
• type: The SELinux context of the object being accessed.
• class: The category of the object (e.g., file, dir, tcp_socket).
• permissions: A space-separated list of actions the domain is allowed to perform on the object (e.g., read, write, execute).

Example:

allow hal_audio_default audio_data_file:file { read write open getattr };

This rule permits the hal_audio_default process to read, write, open, and get attributes of files labeled as audio_data_file.

Common Classes: file, dir, binder, socket

Android's SELinux policy uses various object classes to represent different system resources:

• file: Standard files.
• dir: Directories. Permissions include search, add_name, remove_name.
• binder: Used for inter-process communication via the Binder driver.
• unix_stream_socket / unix_dgram_socket: Unix domain sockets.
• tcp_socket / udp_socket: Network sockets.
• chr_file: Character device files (e.g., /dev/binder).
• property_service: Used for setting system properties.
• hwservice_manager / service_manager: Used for finding and adding Binder services.

Common Permissions: read, write, open, ioctl

The permissions required depend on the object class and the intended operation.

File and Directory Permissions:

• read, write, open: Standard file operations.
• getattr, setattr: Getting or setting file attributes (stat, chmod).
• create: Creating new files.
• unlink: Deleting files.
• search: Required to traverse a directory path.
• ioctl: Required for device-specific ioctl commands (common for character devices).

Binder and Service Permissions:

• call: Allows a domain to send a Binder transaction to another domain.
• transfer: Allows passing Binder references between domains.
• find: Allows querying the servicemanager for a registered service.
• add: Allows registering a new service with the servicemanager.

Macros: AOSP provides macros in te_macros to simplify rule writing. For example:

• r_dir_file(domain, type) expands to rules allowing read access to the directory and files within it.
• binder_call(client_domain, server_domain) expands to the necessary rules for bi-directional Binder communication.

Always prefer using macros when available, as they enforce best practices and reduce boilerplate policy code.