init: Add support for ambient capabilities.
Ambient capabilities are inherited in a straightforward way across
execve(2):
"
If you are nonroot but you have a capability, you can add it to pA.
If you do so, your children get that capability in pA, pP, and pE.
For example, you can set pA = CAP_NET_BIND_SERVICE, and your
children can automatically bind low-numbered ports.
"
This will allow us to get rid of the special meaning for AID_NET_ADMIN
and AID_NET_RAW, and if desired, to reduce the use of file capabilities
(which grant capabilities to any process that can execute the file). An
additional benefit of the latter is that a single .rc file can specify
all properties for a service, without having to rely on a separate file
for file capabilities.
Ambient capabilities are supported starting with kernel 4.3 and have
been backported to all Android common kernels back to 3.10.
I chose to not use Minijail here (though I'm still using libcap) for
two reasons:
1-The Minijail code is designed to work in situations where the process
is holding any set of capabilities, so it's more complex. The situation
when forking from init allows for simpler code.
2-The way Minijail is structured right now, we would not be able to
make the required SELinux calls between UID/GID dropping and other priv
dropping code. In the future, it will make sense to add some sort of
"hook" to Minijail so that it can be used in situations where we want
to do other operations between some of the privilege-dropping
operations carried out by Minijail.
Bug: 32438163
Test: Use sample service.
Change-Id: I3226cc95769d1beacbae619cb6c6e6a5425890fb
diff --git a/init/readme.txt b/init/readme.txt
index 26225b2..e7e369c 100644
--- a/init/readme.txt
+++ b/init/readme.txt
@@ -149,25 +149,33 @@
computed based on the service executable file security context.
user <username>
- Change to username before exec'ing this service.
+ Change to 'username' before exec'ing this service.
Currently defaults to root. (??? probably should default to nobody)
As of Android M, processes should use this option even if they
- require linux capabilities. Previously, to acquire linux
+ require Linux capabilities. Previously, to acquire Linux
capabilities, a process would need to run as root, request the
capabilities, then drop to its desired uid. There is a new
mechanism through fs_config that allows device manufacturers to add
- linux capabilities to specific binaries on a file system that should
+ Linux capabilities to specific binaries on a file system that should
be used instead. This mechanism is described on
http://source.android.com/devices/tech/config/filesystem.html. When
using this new mechanism, processes can use the user option to
select their desired uid without ever running as root.
+ As of Android O, processes can also request capabilities directly in their .rc
+ files. See the "capabilities" option below.
group <groupname> [ <groupname> ]*
- Change to groupname before exec'ing this service. Additional
+ Change to 'groupname' before exec'ing this service. Additional
groupnames beyond the (required) first one are used to set the
supplemental groups of the process (via setgroups()).
Currently defaults to root. (??? probably should default to nobody)
+capabilities <capability> [ <capability> ]*
+ Set capabilities when exec'ing this service. 'capability' should be a Linux
+ capability without the "CAP_" prefix, like "NET_ADMIN" or "SETPCAP". See
+ http://man7.org/linux/man-pages/man7/capabilities.7.html for a list of Linux
+ capabilities.
+
seclabel <seclabel>
Change to 'seclabel' before exec'ing this service.
Primarily for use by services run from the rootfs, e.g. ueventd, adbd.