Which access rights can't the superuser violate?

Question

Fr. Br. George told in one of his lectures (it's in Russian) that there are some access rights that superuser can not violate. That is there are some access right which can forbid superuser doing something.

I was not able to find this information on the Internet and I'm curious what they are. This is probably something related to the system's core execution, isn't it? Maybe he can not stop some system processes? Or maybe he can not run a process in real mode?

This question is no related to SELinux (George was talking about it right before the question).

Solution 1

acess denied to root:

root can be denied direct network access. This is useful on internet connected hosts, as it requires that you login as smith, then sudo.

some stuff root can't do:

This is NOT for a lack of privilege. I can't see anything root couldn't do, however some technical issues might be experienced as "forbidden".

I am root, why can't I create/delete this file, while ordinary user can?

You are on a NFS/samba share, and you weren't give specific (access=) authorization. Ordinary user fail to common law. (see local vs remote root below)

I am root, why can't I kill this process?

There is a pending I/O and physical drive/remote LUN have been disconnected, process can only be killed by reboot.

I am root, how do I get archemar's password?

You can su - archemar all right, or change archemar's password without knowing the previous one, but you can't read it (short of a key logger), since passwords are stored using a one-way hash.

local vs remote root

• You can be root on your station/PC, and use a company/college/university/provider NFS share.
• Next you can have only a non-root login on computer exporting NFS.

Now

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

simply log on NFS server, run ./bash and you are root on company/university server.

Solution 2

In the usual case, this is incorrect - the superuser has privileges / permissions to any functionality the system provides(1). Where this rule breaks down is when you throw SELinux into the mix. With SELinux, it is possible to restrict even root's privileges to disallow certain actions. However, the specific actions disallowed are highly dependent on the local machine's SELinux configuration, so even with SELinux, this question cannot be answered in the general sense.

(1) - if a system does not provide a given feature, e.g. there is no real-time kernel functionality, then I am considering the statement "root does not have access to this functionality" to be false, since that statement relies on a false assumption (namely that the given feature is available to anyone on that system)

Solution 3

On one hand, there are things that no user can do, such as

• hard-linking directories (because of file system limitations)
• writing to an already burned CD-ROM (because physics)

But those are not privileges, because they cannot be granted, they are just not possible for anyone.

Then there are restrictions for the entire system or parts of it that can be turned on or off.
For example, on OS X there is an option to only allow code to run if it has been signed by Apple.

I don't consider this an actual privilege either, because no user can have it if the superuser can't. You can only globally disable it.

Edit:
Your idea of a file without the executable bit would also fall in this category, as literally no-one is able to do that, and no-one can be granted that permission.
And even when giving another user or group the permission to execute that file, but not root or a user group root is in, root will still be able to execute that file (tested on OS X 10.10, 10.11 and Ubuntu 15.04 server).

Apart from those cases, there is barely anything root cannot do.
There is, however, a thing called kernel mode (as opposed to user mode).

As far as I know, on a sane system only the kernel, kernel extensions and drivers run in kernel mode, and everything else (including the shell from which you log in as root) run in user mode.
You could therefore argue that "being root is not enough". However, on most systems the root user is able to load kernel modules, which will in turn run in kernel mode, effectively giving root a way of running code in kernel mode.

There are systems, however, (like iOS) where this is not (arbitrarily) possible, at least not without exploiting security wholes. This is mostly due to increased security, like code signing enforcement.
For example, there are AES encryption keys built into the processors of iDevices, which can only be accessed from kernel mode. Kernel modules could access those, but the code in those kernel modules would also have to be signed by Apple in order for the kernel to accept them.

On OS X, since version 10.11 (El Capitan) there is also a so-called "rootless mode" (although the name is misleading because root still exists), which effectively forbids root certain things that installers can still do.
Quoting from this excellent answer on AskDifferent:

Here's what it restricts, even from root:

• You can't modify anything in /System, /bin, /sbin, or /usr (except /usr/local); or any of the built-in apps and utilities. Only Installer and software update can modify these areas, and even they only do it when installing Apple-signed packages.

Solution 4

One example could be modifying of immutable file: You can set a file attribute i with chattr that makes the file immutable even for root. For example:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Note that the file appears as normal writable file in ls -l output:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

To see the i attribute, you have to use lsattr:

# lsattr god
----i----------- god

The manual page of chattr states following about the i attribute:

A file with the `i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Though, root can easily undo the immutability:

# chattr -i god
# rm -v god
removed ‘god’

Solution 5

The "system core execution" you're mentioning is well under root's control e.g. via loadable kernel modules. Of course, this assumes loading kernel modules is supported by the kernel, noone can perform actions which are not feasible, even root.

The same is true for system processes. root is allowed to kill any process, but it's impossible to stop a process running in kernel mode without compromising kernel integrity, so it's simply unfeasible to stop such processed immediately. Note that root will not be denied to kill those processes, killing itself will simply have no effect.

Finally, the real mode: Linux kernel has no support for it, so again, noone can do the infeasible, not even root.

@Siguza mentioned execution of files without the x permission, which is quite possible for the root user:

/lib/ld-linux.so.2 /path/to/executable

View more solutions

Comments

[MSalters]

A "privilege" or "permission" is a right to do something, a right that can be granted to specific user accounts. In UNIX and Linux (excluding hardened versions such as SELinux), root has all rights. There's no right that can be granted to root, and therefore no right that can be taken away from root.

[Charles Duffy]

@MSalters, pardon? One can certainly keep UID 0 while still revoking process capabilities.

[Charles Duffy]

...set SECBIT_NOROOT, and being uid 0 no longer grants one capabilities automatically.

[Simon Richter]

So many answers -- would it make sense to turn this into a community wiki, or should someone write a summary answer?

[Kolyunya]

@SimonRichter I'm also going to as George to tell us what he meant in his lecture.

[MSalters]

@CharlesDuffy: Except for Linux source code links and one unanswered question, your comment is the highest Google reference to SECBIT_NOROOT. Never heard of it. Probably a bit weak on the Google side, though, as man capabilities mentions it. But capabilities are a bit different - they're process capabilities, where my comment referred to rights of user accounts. SECBIT_ROOT only is relevant because it declines capabilities to a process which would otherwise be granted exactly because the root account running the process has all rights.

[Charles Duffy]

Ahh -- I wasn't clear that you only meant to ask about account-based rights.

[Charles Duffy]

...that said, there are certainly systems like Kerberos and AFS where you need tokens to do network operations; root can steal them from other users on the same system, but not necessarily trivially (Kerberos tickets depend on filesystem permissions and can be easily stolen; AFS tokens are trickier).

[Kolyunya]

Thank you for your answer, John! But he explicitly stated that this question is not related to SELinux...

[MSalters]

Case 1 is basically an error because you're only root locally, not necessarily on other systems. Case 2 and 3 aren't privileges (they can't be granted to anyone). So +1, your first sentence appears to be correct.

[Tom Hunt]

Technically, root on local machine could do anything it likes with the same privilege as local user, by su - username if nothing else. I'm never sure why they bothered making root unable to write network shares like that; it seems rather pointless.

[Tom Hunt]

Yeah, but if any user on your box has some NFS access, root also has that access (via any number of methods, simplest of which is su -). So it doesn't seem like it's any greater security to deny root that access via normal methods.

[doneal24]

You also have the complication that root controls the SELinux configuration. If I (as root) am blocked in an action I can modify SELinux to allow the action and then change it back afterwards. Might get away with it depending on where the log trail is stored.

[doneal24]

Actually, you can can run an executable without the execute bits set: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./hello gives the expected Hello, World! output,

[Siguza]

@DougO'Neal But isn't /lib64/ld-linux-x86-64.so.2 the actual executable then, and ./hello just an argument to it? Because that's like passing a text file containing PHP code to the PHP interpreter... or like running a bash script using bash ./my_script...

[Charles Duffy]

Not necessarily true. Take away its CAP_NET_ADMIN, and being uid 0 still doesn't let a process change network configuration. (Likewise for CAP_SYS_ADMIN and the abilities it controls, etc).

[Charles Duffy]

...but a uid-0 process can lose the ability to load new kernel modules (or hotpatch them in through /proc/kmem) via capability revocation.

[Mark]

@TomHunt, one of the reasons not to give root access to NFS shares is to prevent the creation of "suid root" binaries on the remote server, something that can be leveraged into complete remote access to the server.

[user2071406]

“You can su - archemar all right, change password without knowing previous one, but you can't guess it (short of a key logger), password are store in a one-way hash.” — No, being root does not mean you can break mathematics.

[user2071406]

Killing a process in uninterruptible wait doesn't seem like a right to me. It's something that you just can't do. Like writing to a full filesystem.

[Joshua]

root can't execute a binary that has all execute permissions revoked.

[Simon Richter]

The Linux kernel does not properly implement the BSD securelevel facility (anymore), giving you diminishing returns on immutable and append only attributes. With securelevel, these bits cannot be reset once the system is in a multiuser runlevel, so the admin would have to shut down and use a local console, which would stop network attackers.

[doneal24]

@duskwuff How recent a version of glibc? This still works under Ubuntu 14.04.

[psmears]

The NFS privilege escalation thing doesn't usually work in practice for obtaining root on the server, because NFS servers generally are set up to treat anyone claiming they're "root" as if they're actually "nobody" (this feature is called "root squash" and is enabled by default on modern systems).

[LazyBones]

You can link directories under OS X (well on its normal file system HFS)

[Siguza]

@Mark bash$ ln Desktop test => ln: Desktop: Is a directory I think you're talking about symlinks... there are NTFS junctions, but that's another story...

[Charles Duffy]

@Joshua, untrue -- root can simply invoke the dynamic loader against it directly.

[Joshua]

@CharlesDuffy: When's the last time you tried it?

[user253751]

Case 1 is a case where you're prevented from becoming root, not where root is prevented from doing something. (You are forbidden from doing something, but it's irrelevant to the question since you're not root yet)

[LazyBones]

Apple did not add it to ln but the system class that ln uses e.g. link do allow this see stackoverflow.com/a/4707231/151019 This is the way Time Machine works