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

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

Answer 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)

Answer 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) runs 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 holes. 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.

Answer 4

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

Answer 5

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’

Answer 6

On FreeBSD, you can't use gmirror on an already mounted partition, even as root :

gmirror label -v -b prefer gm0s1 ad4s1
gmirror: Can't store metadata on ad4s1: Operation not permitted.

You have to set a sysctl (kern.geom.debugflags=16) to be able to do it.

root is a privileged user, but these rights are given by kernel. So the kernel has got more privileges than root.

Answer 7

Assuming collaboration from the root user itself, root can be prevented from accessing FUSE mounts (with the allow_other or allow_root options), but this is because FUSE was designed to act this way. Since FUSE resides on a virtual layer, it can return any error it likes based on logic, as opposed to common block device modules that strive to be as transparent and thin as possible, delegating permissions to another layer.

This does not prevent the root user from disabling the option, or replacing the FUSE module with one that silently discards the option, unless you make the filesystem read-only. However, this only leads to a "who watches the watchmen" situation: how can you validate that the system is not lying? Your shell might even be sitting in a chroot that shows you a legitimate FUSE module, while the kernel is actually running a malevolent version of it.

Answer 8

I would say that the inability to execute non-executable files is trivially a limitation, as it depends on file permissions. (It is possible to get around this using /lib64/ld-linux-x86-64.so.2 for a nonexecutable file, but not a file on a no-exec mount)

There's also the issue of mandatory file locks, which prevent file editing if a file is currently being used by a process, although the super user can kill the process.

At one point, the super user could not unmount a device while the device was busy, but this can now be done using a lazy umount.

Other limitations are:

cannot modify immutable files, and can only append to append-only files (linux allows the super user to remove the immutable and append only flags at any run-level, however, partly defeating the purpose of them)

cannot write to a read-only mount, or execute anything on a no-exec mount

cannot bind an unbindable mount

cannot remount a file system as read-write if its block device is read-only

cannot stat anything on a fuse mount owned by another user, unless it's mounted allow-other or allow-root

cannot violate SELinux settings

deliberate limitations inherent in the system itself, which affect root:

cannot directly set the c-time of a file (or the birth time, if it's ever implemented)

cannot view passwords as plain text