Ambient capabilities

Capabilities allow Linux processes to drop most root-like privileges while retaining the subset of privileges that they require to perform their function. The original implementation of capabilities made it impossible for fork+exec'd processes to inherit capabilities unless the files being executed had file capabilities configured. File capabilities, in turn, present a security risk since any process executing a file with file capabilities can gain those capabilities.

Ambient capabilities allow system services launched by init to configure capabilities in their .rc files, bringing configuration into a single file instead of splitting configuration in the fs_config.c file. This means that for any service launched by init, you can use the .rc file associated with the service to configure capabilities for that service.

Ambient capabilities are the preferred mechanism for setting capabilities for services launched by init (this method keeps all aspects for the service configuration in a single .rc file). We recommend using ambient capabilities instead of configuring file system capabilities using the caps section in config.fs files.

When setting capabilities for services not launched by init, continue to configure file system capabilities using fs_config.c.

Enable ambient capabilities

To enable ambient capabilities for a given service, use the capabilities keyword in init. For current init language details, refer to the init README.md.

For example, to enable ambient capabilities for the AOSP service wificond, the .rc file for the wificond service sets up the appropriate user and groups and gives the service the specified capabilities using the capabilities keyword:

service wificond /system/bin/wificond
    class main
    user wifi
    group wifi net_raw net_admin
    capabilities NET_RAW NET_ADMIN

Reference implementation

The reference implementation is the Android common kernel https://android.googlesource.com/kernel/common/

Required patches

Note: The Android kernels 3.10 (android-3.10) and 3.14 (android-3.14) have been deprecated and removed.

Required patches have been backported to all the relevant Android common kernel branches.

The main ambient capabilities patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08 has been backported in:

• android-3.18:
  • https://android.googlesource.com/kernel/common/+/d6a9a74487e86b528c44965f871de75671b6adb0
• android-4.1:
  • https://android.googlesource.com/kernel/common/+/0381789d78d552462ef576d9759e9aa6fcaae3bb

A small security fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b7f76ea2ef6739ee484a165ffbac98deb855d3d3 has been backported in:

• android-3.18:
  • https://android.googlesource.com/kernel/common/+/7bc0ef844a537ebb786ba0574932bd65751818c6
• android-4.1:
  • https://android.googlesource.com/kernel/common/+/dda568cc40d855bde2dfa9c04a7a1628c80b7f63

Validation

Bionic unit tests include unit tests for ambient capabilities. Beyond that, using the "capabilities" keyword in Android init for a service, and then checking that the service gets the expected capabilities would allow for runtime testing of this feature.