neverallow Rules

While allow rules grant permissions, neverallow rules represent hard boundaries in the SELinux policy that must not be crossed. They are assertions that the SELinux policy compiler (checkpolicy) enforces at build time.

The Purpose of neverallow

The primary purpose of neverallow rules is to prevent the introduction of overly broad or insecure allow rules. In a large project like Android, many developers might write policy to get their specific feature working. Without safeguards, someone might add an allow rule that inadvertently compromises the entire system's security.

For example, a developer trying to fix a crash in the mediaserver might try to grant it access to all data files:

# Bad practice!
allow mediaserver system_data_file:file rw_file_perms;

To prevent this, AOSP includes a neverallow rule:

neverallow mediaserver { system_data_file core_data_file_type }:file { write append };

If a developer adds the bad allow rule, the build will fail with a policy violation error, forcing them to find a more precise and secure solution.

CTS neverallow Tests

Android's Compatibility Test Suite (CTS) includes SELinux policy tests. When a device manufacturer modifies the AOSP SELinux policy (usually in the device/<vendor>/<board>/sepolicy directory), they must ensure they do not violate any core neverallow rules defined by Google.

CTS extracts the policy from the device and runs checkpolicy against it to verify compliance. If a vendor adds an allow rule that conflicts with a Google-defined neverallow, the device will fail CTS and cannot be certified.

Common neverallow Violations and Fixes

When you encounter a neverallow violation during an Android build, the error message will show the conflicting allow rule and the neverallow rule it violates.

Example Violation:

libsepol.check_assertions: 1 neverallow failures occurred
Error while expanding policy
...
neverallow rule violated:
  allow untrusted_app default_prop:property_service set;

How to Fix:

1. Never delete the neverallow rule: Unless you are modifying core AOSP infrastructure (and know exactly what you are doing), do not modify Google's neverallow rules.
2. Refine your allow rule: The most common cause is using a type that is too broad. Instead of allowing an app to read system_data_file, create a specific type (e.g., my_app_data_file), label the target files with that type, and allow access only to that specific type.
3. Use a different architecture: If the policy strictly forbids direct access (e.g., an app directly writing to a character device), you must use an intermediary service (like a Binder service or HAL) that has the appropriate permissions to perform the action on behalf of the client.