Are there any Google devices that support file based capabilities in their default kernel?

Question

If I systemless root (no modification done to /system partition) a Nexus device, would I be able to able to set capabilities on executables without changing the original kernel binary ?

I often want to manage files without restrictions from my terminal (requireCAP_DAC_READ_SEARCH). However, I also want to not use the superuser.
The required things are tools for setting caps along kernel support for using them (it doesn't rely on other user space things).

The problem is, I don’t own such device. So I can’t tell if it would work on any of Nexus 5X Nexus 6P Nexus 9 Pixel C.

Answer 1

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:

• What special privileges “/system/xbin/su” does have w.r.t. root access?
• Permissions, Root User and Linux Capabilities: Linux vs. Android