Does a process run by root always have all of the capabilities available in Linux?

Question

In Linux, a process run by a non-root user can have some capabilities assigned to it to increase its privileges.

And a process that's run by the root user has all of the capabilities available, but can such a process have some of its capabilities removed, either manually or automatically in certain situations?

Answer 1

Yes, the idea of capabilities is that the user id itself doesn't give any special abilities. An UID 0 process can also drop unneeded capabilities. It would still retain access to files owned by UID 0 (e.g. /etc/shadow or /etc/ssh/sshd_config), so switching to another UID would still likely be a smart thing to do in addition.

We can test this with capsh, it allows us to drop capabilities as requested. Here, the last part is run as a shell script, and we can see that the chown fails since the ability to change file owners (CAP_CHOWN) was dropped:

# capsh --drop=cap_chown -- -c 'id; touch foo; chown nobody foo'
uid=0(root) gid=0(root) groups=0(root)
chown: changing ownership of 'foo': Operation not permitted

The capabilities(7) man page mentions that the system has some safeguards in place for setuid binaries that don't know about capabilities and might not deal well with a situation where some are permanently removed. See under "Safety checking for capability-dumb binaries".

The same man page of course contains other useful information on capabilities, too.

Answer 2

There are a few other things you can do.

root_squash

NFS shares can be made available with the root_squash flag.

In this way, a network share can be mounted but a root user on the client is not given root access to files hosted on the server that makes the NFS available. In this you can make files accessible to another host and even if a user on that host has root on their box, your content is still safe.

This is useful in Enterprise environments for example if you want to allow your Network admins to have access to logs for their devices but don't want them to be able to make any changes. Even though they have root on their linux admin box, they can't alter the logs.

Here's my favorite guide if you want to read further: http://fullyautolinux.blogspot.com/2015/11/nfs-norootsquash-and-suid-basic-nfs.html

ssh

There are a couple of other things you can do. For example you can prevent root from being able to SSH to the device. This means that to become root, a user would need to access the device using a different account (e.g. an admin account you made), and then switch to the root user with a command like su.

A simple guide can be found here: https://mediatemple.net/community/products/dv/204643810/how-do-i-disable-ssh-login-for-the-root-user

RHEL7/CentOS7

Here is some doco from Redhat on how to limit the root account in enterprise environments: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-controlling_root_access

Update:

As discussed in other answers, you can also change the capabilities of the root account.

Answer 3

Programmatically adjusting capability sets

A thread can retrieve and change its capability sets using the capget(2) and capset(2) system calls. However, the use of cap_get_proc(3) and cap_set_proc(3), both provided in the libcap package, is preferred for this purpose. The following rules govern changes to the thread capability sets:

...

3. The new permitted set must be a subset of the existing permitted set (i.e., it is not possible to acquire permitted capabilities that the thread does not currently have).
4. The new effective set must be a subset of the new permitted set.

-- capabilities(7)

Answer 4

I am adding information to @ilkkachu answer.
It seems that the capabilities of the process determines if the user is privileged or not.

For example, let's remove all the capabilities except one (cap_checkpoint_restore):

capsh --drop=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf -- -c 'sleep 10000'

We can see that this user has only one capability cap_checkpoint_restore, even when the user is root:

#  ps aux | grep sleep
root     2309662  0.0  0.0   5768  1008 pts/5    S+   07:21   0:00 sleep 10000

# cat /proc/2309662/status | grep Cap
CapInh: 0000000000000000
CapPrm: 0000010000000000
CapEff: 0000010000000000
CapBnd: 0000010000000000
CapAmb: 0000000000000000

# capsh --decode=0000010000000000
0x0000010000000000=cap_checkpoint_restore