Though the question is old, it keeps on appearing on top of Unanswered (my tags) questions. So I think I should answer this :)
AOSP'S SUPPORT FOR CAPABILITIES:
Question is specifically about Google devices, I have never used a Google device. However what I can say for sure is that Linux (process) capabilities must have been enabled on most of the devices (if not all) running as low as Android 1.6. Reference is found in
system_server, both very primary components of AOSP. In Android 4.2, for instance,
installd - another core component - was made to run with dropped capabilities.
Filesystem capabilities were one of the major Security Enhancements in Android 4.3 which removed
set-gid from binaries like
run-as, setting file capabilities on them. This caused revolutionary changes in Android's rooting journey.
Support for Ambient capabilities was added in Android 8 which discourages the use of file capabilities:
File capabilities, in turn, present a security risk since any process executing a file with file capabilities will be able to gain those capabilities.
init services depend on them e.g.
storaged, including my own
KERNEL'S SUPPORT FOR CAPABILITIES:
Coming to the kernel part, building kernel without capabilities isn't optional:
From kernel 2.5.27 to kernel 2.6.26, capabilities were an optional kernel component, and could be enabled/disabled via the CONFIG_SECURITY_CAPABILITIES kernel configuration option.
In kernels before Linux 2.6.33, file capabilities were an optional feature configurable via the CONFIG_SECURITY_FILE_CAPABILITIES option. Since Linux 2.6.33, the configuration option has been removed and file capabilities are always part of the kernel.
The oldest common kernel version on Android repositories is 2.6.39 which includes support for file capabilities too.
Support for filesystem capabilities on kernel side must have been delayed from some OEMs but they had to switch, because otherwise functionalities would break. For instance
surfaceflinger (Android's surface composer) won't work without file capabilities since Android 7.1.
Mainline Linux kernel 4.3 was patched in in Sep'15 for Ambient (process) capabilities, backported to Android kernel 3.18 and 4.1 in 2016. So they are necessarily a part of kernel.
On Linux distros, a very few programs make use of Linux capabilities. Though there is
pam_cap, mostly (or all?) distros still use
passwd and so on. But on Android capabilities are deeply integrated in framework and core services. Removing them would require editing hundreds or may be thousands of lines in AOSP and kernel source. It makes no sense that an OEM (particularly Google, who developed AOSP and modified Linux kernel for Android) doesn't make use of this free-of-cost security feature when it's readily available in Android kernel. It's a pure OS related feature, doesn't demand any extra hardware support. So any phone from any manufacturer must have capabilities supported.
would I be able to able to set capabilities on executables without changing the original kernel binary?
Yes, you must be.
The required things are tools for setting caps ...
I have been using
libcap-ng without any problems. But I prefer Ambient capabilities, those are easy to configure and don't depend on any filesystem features like Extended Attributes as in case of file capabilities. You can also use
removexattr tools from
xattr_syscall_wrapper to manipulate
security.capability or any other XATTR directly.
From your comment:
I just noticed the
/system/bin/ping command isn’t
setuid on my real Samsung device, suggesting
Android's ping neither has
CAP_NET_RAW. It creates a special non-RAW socket
IPPROTO_ICMP which - unlike
IPPROTO_RAW - doesn't require any privileges.
In addition to 10+ references given above, here are a few other parts of AOSP code supporting and making use of Linux capabilities:
- Core components: Bionic
- External components:
- Daemons / services:
zygote (forked apps and
NetLink manager, private DNS),
wificond, a number of HAL daemons including
- Minijail: A dedicated sandboxing tool and library which revolves around capabilities.
adbd makes use of this library to drop privileges.
- SELinux uses
capability class to grant / deny capabilities to domains.
It concludes that Android highly depends on Linux capabilities, it's not a little-used feature.