0

Linux does not treat the "root" user as the superuser anymore, but rather Linux uses capabilities which gives a process privileges (I think BSD does a similar thing).

So for example in older Linux versions, Linux would allow a process to create a socket if the process's EUID (or FSUID, not sure) is "root", but in modern Linux versions, Linux would allow a process to create a socket only if the process has the required privilege that allows a process to create a socket.

But I am wondering, are there some Unix or Unix-like operating systems that still treats the "root" user as the superuser?

user7681202
  • 1,313
  • 3
  • 14
  • 27

1 Answers1

5

The premise of the question is mostly flawed. Linux does treat user 0 as the superuser. (It was always user 0; calling that user root is just a convention.) Capabilities are an additional mechanism that allows non-root processes to receive specific privileges. User 0 normally effectively has all the capabilities, so root remains the superuser.

A process running with effective user id 0 can lose capabilities, but this does not limit its power except in highly controlled environments. Any process that's running with effective user id 0 and can create an executable file and can call execve can execute arbitrary code with all the capabilities, since execve does not preserve the process's capability mask when the effective user id is root. (See “Capabilities and execution of programs by root” in the manual.)

It is possible to make an operating system that completely strips access to some capabilities while still using user id 0, by setting the SECBIT_NOROOT flag during login and making sure that there's no way to gain it back, or by removing capabilities from the bounding set. But that's not how Linux (as in, the Linux operating system) normally works. It's an extra feature of the kernel that is useful for restricted operating systems (for example inside containers).

Capabilities can limit the power of root, but it isn't easy to use them that way and that's no what they're mostly used for: capabilities are primarily used to avoid running processes as root. The Linux kernel does have other features that limit the power of root. Security modules such as SELinux and AppArmor apply regardless of the user id, so it's possible to set up a system where user id 0 can do pretty much nothing (but again, that's not how a normal system is set up). With user namespaces, user id 0 is only the superuser inside that namespace, and this feature is widely used with containers.

FreeBSD offers Capsicum capabilities. I don't know if Capsicum limits the power of user id 0. Once again, the primary goal of capabilities is to reduce the amount of code running with all privileges, not to remove the concept of an all-privileged process.

I don't think any of the other BSD have a capability mechanism. OpenBSD aims to be secure by minimizing the complexity and amount of privileged code. Increasing the complexity of the security mechanisms in order to reduce the amount of privileges that privileged code isn't a free lunch.

Gilles 'SO- stop being evil'
  • 829,060
  • How can a root process (or its descendants) regain a capability which was dropped from its bounding set with prctl(PR_CAPBSET_DROP)? –  Aug 29 '19 at 00:13
  • @mosvy I don't think it can, so I've added a mention of that, thanks. – Gilles 'SO- stop being evil' Aug 29 '19 at 00:23
  • The process may regain caps dropped from the bounding set if these caps are still in its inheritable set and the process executes a binary with these caps in inheritable file caps. This case is very uncommon to see, but this is possible theoretically. To drop some cap completely, the process has to drop it from both bounding and inheritable sets. – Danila Kiver Aug 29 '19 at 12:11