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.

  • 2
    I was also unable to find a nexus emulator… Commented Apr 11, 2016 at 21:15
  • I doubt it... Since Android uses Bionic libc and not the standard GNU libc (glibc) library, it is not even close to POSIX compliant. You might be able to compile your own kernel with a different libc like CrystaX NDK instead of Bionic, but I don't know if those features are in that either.
    – acejavelin
    Commented Apr 12, 2016 at 0:54
  • @acejavelin : the userland part is only required for setting extended attributes containing capabilities. Everything else is kernel side. I just noticed the/system/bin/pingcommand 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. Commented Apr 12, 2016 at 1:02
  • Why would you not root a Nexus device? It is intended for that and does not void your warranty. It is very simple to restore any Nexus device to it's default, unrooted and locked state, the device is basically unbrickable.
    – acejavelin
    Commented Apr 12, 2016 at 1:05
  • @acejavelin : I don’t own a nexus device… My aim is security research and google only reward for it’s own devices. So I need to know if the kernel of one of the devices in my question support using capabilities xattr. What I’m seeing on my galaxy tab is probably only samsung related. If I don’t involve rooting in my question it might be closed as unclear. Commented Apr 12, 2016 at 1:21

1 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 :)


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.


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 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.


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.


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.


  • Doesn’t answer anything at all. Everything you stated is known. The point of the question is since it’s little‑used is wether Google branded devices include it. Commented Sep 1, 2019 at 20:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .