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 init
and 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-uid
/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.
Many init
services depend on them e.g. storaged
, including my own sshd
and dnscrypt-proxy
services.
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.
And:
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.
CONCLUSION:
On Linux distros, a very few programs make use of Linux capabilities. Though there is pam_cap
, mostly (or all?) distros still use set-uid
on su
, sudo
, ping
, mount
, 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.
QUESTIONS:
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 capsh
, getcap
, setcap
, getpcaps
from libcap
and netcap
, pscap
from 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 listxattr
, getxattr
, setxattr
and 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 CAP_NET_RAW
Android's ping neither has set-uid
nor CAP_NET_RAW
. It creates a special non-RAW socket IPPROTO_ICMP
which - unlike IPPROTO_RAW
- doesn't require any privileges.
FURTHER REFERENCES:
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
libc
, init
, trusty
(OS)
- External components:
libcap
, libcap-ng
- Daemons / services:
zygote
(forked apps and system_server
), hostapd
, wpa_supplicant
, dnsmasq
, logd
, netd
(NetLink
manager, private DNS), debuggerd
(test), sdcard
daemon, performanced
, incidentd
, mtpd
, traced_probes
(perfetto), racoon
(IPSec), wificond
, a number of HAL daemons including rild
.
- Executables:
reboot
(init), dumpstate
, tcpdump
, strace
, iputils
(ping
, traceroute
etc.)
- 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.
RELATED:
/system/bin/ping
command isn’t setuid on my real samsung device, suggestingCAP_NET_RAW
. However, I won’t root a real device and I don’t know which tool I can use to see the relevant informations, so I can’t check.