Cdtjkyj

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

And a process that have the root user have all of the capabilities available, but can such a process have some of its capabilities removed (either manually or automatically in certain situations)?

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.

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)

There are a few things you can do.

root_squash

One caveat I can think of is that 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.