Contexts

In SELinux, every subject (process) and object (file, socket, property) is assigned a security context. This context is a string that represents the security attributes used by the SELinux policy engine to make access control decisions.

Security Context Format: user:role:type:level

The security context is a colon-separated string with four components: user:role:type:sensitivity_level.

u:object_r:system_file:s0

• User (u): SELinux users are different from standard Linux users. In Android, the user component is almost always u for subjects and objects.
• Role (r or object_r): Roles represent sets of domains a user can enter. For processes, the role is typically r. For files and other passive objects, the role is always object_r.
• Type (system_file): This is the most crucial component in Android's Type Enforcement (TE). It specifies the domain for processes or the type for objects. Access control rules are almost exclusively based on this component.
• Level (s0): Used for Multi-Level Security (MLS) and Multi-Category Security (MCS). Android uses MCS to isolate application data. s0 is the default sensitivity. Apps are assigned categories (e.g., s0:c512,c768) to separate their data from other apps.

File Contexts (file_contexts)

The file_contexts files define the SELinux labels for files and directories on the filesystem. These mappings are applied during the build process and when the device boots.

Example from system/sepolicy/private/file_contexts:

/system/bin/app_process32      u:object_r:zygote_exec:s0
/data/local/tmp(/.*)?          u:object_r:shell_data_file:s0

When creating a new file or directory, it typically inherits the context of its parent directory unless a specific transition rule is defined.

Process Contexts (.te files)

A process's context is defined by its domain. The domain transition rules in .te files determine how a process acquires its domain. When an executable is launched, it typically transitions from the domain of the parent process to a new domain based on the type of the executable file.

Example:

domain_auto_trans(init, hal_audio_exec, hal_audio_default)

This macro indicates that when the init domain executes a file labeled hal_audio_exec, the new process transitions to the hal_audio_default domain.

Property Contexts (property_contexts)

System properties are also protected by SELinux. The property_contexts file maps property prefixes to SELinux types.

Example from system/sepolicy/private/property_contexts:

ro.build.       u:object_r:build_prop:s0
sys.usb.        u:object_r:system_prop:s0

To read or write a property, a process's domain must have the corresponding permissions (e.g., set_prop or get_prop) for that property type.

Service Contexts

Binder services registered with the servicemanager or hwservicemanager require SELinux contexts. These are defined in service_contexts and hwservice_contexts files.

Example from system/sepolicy/private/service_contexts:

activity        u:object_r:activity_service:s0
package         u:object_r:package_service:s0

When a process attempts to look up or add a Binder service, the servicemanager checks the SELinux policy to verify if the process's domain has the required find or add permissions for the service type.