23

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

l0b0
  • 50,672
  • 41
  • 197
  • 360
Kolyunya
  • 579
  • 2
  • 7
  • 16
  • 2
    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`. – MSalters Oct 26 '15 at 14:00
  • 1
    @MSalters, pardon? One can certainly keep UID 0 while still revoking process capabilities. – Charles Duffy Oct 26 '15 at 17:38
  • ...set `SECBIT_NOROOT`, and being uid 0 no longer grants one capabilities automatically. – Charles Duffy Oct 26 '15 at 17:44
  • So many answers -- would it make sense to turn this into a community wiki, or should someone write a summary answer? – Simon Richter Oct 26 '15 at 23:00
  • 1
    @SimonRichter I'm also going to as George to tell us what he meant in his lecture. – Kolyunya Oct 26 '15 at 23:04
  • @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`](http://linux.die.net/man/7/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. – MSalters Oct 27 '15 at 23:29
  • Ahh -- I wasn't clear that you only meant to ask about account-based rights. – Charles Duffy Oct 27 '15 at 23:33
  • ...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). – Charles Duffy Oct 27 '15 at 23:37

8 Answers8

25

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.

Daniel Griscom
  • 201
  • 1
  • 13
Archemar
  • 31,183
  • 18
  • 69
  • 104
  • 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. – MSalters Oct 26 '15 at 13:57
  • 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 Oct 26 '15 at 14:48
  • 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. – Tom Hunt Oct 26 '15 at 14:52
  • 4
    It's the age old question "Can `root` create a password even he can't access?" – corsiKa Oct 26 '15 at 15:56
  • 5
    @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. – Mark Oct 26 '15 at 18:24
  • “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. – Blacklight Shining Oct 26 '15 at 19:26
  • 1
    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. – Blacklight Shining Oct 26 '15 at 19:27
  • root can't execute a binary that has all execute permissions revoked. – Joshua Oct 26 '15 at 20:45
  • 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). – psmears Oct 27 '15 at 16:56
  • @Joshua, untrue -- root can simply invoke the dynamic loader against it directly. – Charles Duffy Oct 27 '15 at 23:34
  • @CharlesDuffy: When's the last time you tried it? – Joshua Oct 28 '15 at 01:09
  • 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) – user253751 Oct 28 '15 at 01:58
12

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)

John
  • 16,759
  • 1
  • 34
  • 43
  • 1
    Thank you for your answer, John! But he explicitly stated that this question is not related to SELinux... – Kolyunya Oct 26 '15 at 12:08
  • Then barring further details, I'm going to have to consider the statement that root doesn't have access to certain functionality to be false. (I'm not considering the case of the OS being locked out of the BIOS or similar by BIOS security.) – John Oct 26 '15 at 12:10
  • 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 Oct 26 '15 at 15:51
  • 2
    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 Oct 26 '15 at 17:39
7

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.
AdminBee
  • 21,637
  • 21
  • 47
  • 71
Siguza
  • 297
  • 1
  • 12
  • 1
    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, – doneal24 Oct 26 '15 at 16:51
  • @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`... – Siguza Oct 26 '15 at 16:57
  • 1
    @DougO'Neal That used to work, but was disabled in recent versions of glibc (to prevent it from being a trivial bypass of noexec mounts). –  Oct 26 '15 at 18:09
  • @duskwuff How recent a version of glibc? This still works under Ubuntu 14.04. – doneal24 Oct 27 '15 at 13:56
  • You can link directories under OS X (well on its normal file system HFS) – mmmmmm Oct 27 '15 at 22:52
  • @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... – Siguza Oct 27 '15 at 23:22
  • 1
    Apple did not add it to ln but the system class that ln uses e.g. link do allow this see http://stackoverflow.com/a/4707231/151019 This is the way Time Machine works – mmmmmm Oct 28 '15 at 11:06
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
Dmitry Grigoryev
  • 7,123
  • 2
  • 23
  • 62
  • ...but a uid-0 process can lose the ability to load new kernel modules (or hotpatch them in through `/proc/kmem`) via capability revocation. – Charles Duffy Oct 26 '15 at 17:41
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’
Tuomas
  • 250
  • 2
  • 6
  • 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. – Simon Richter Oct 26 '15 at 22:59
2

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.

Vinz
  • 2,120
  • 12
  • 16
1

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.

sleblanc
  • 1,099
  • 11
  • 16
0

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

anotherguy
  • 463
  • 1
  • 5
  • 9