3

Does the root user bypass capability checking in the kernel, or is the root user subject to capability checking starting with Linux 2.2?

May applications check for and deny access for the root user, if certain capabilities are dropped from its capability set?

By default the root user has a full set of capabilities.

The reason I'm asking is the following except from man capabilities:

Privileged processes bypass all kernel permission checks

However, nothing is said whether this rule still holds after Linux 2.2 release.

Extra: Docker removes certain capabilities from the root user while starting a new container. However, Docker doesn't use user namespaces by default, so how is the root user's capabilities restored?

man capabilities:

For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list).

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

2 Answers 2

Reset to default
3

The root user can be constrained in its set of capabilities. From capabilities(7):

If the effective user ID is changed from nonzero to 0, then the permitted set is copied to the effective set.

This implies that in the capability model, becoming the root user does not grant all permissions, unlike in the traditional model, where it does. The capability model is used in Linux 2.2 and later.

The bounding set of capabilities for a process is inherited from its parent. When Docker drops capabilities from the bounding set for the thread starting the container, those capabilities are dropped for the the container, affecting every process of that container, whether for the root user or otherwise. The capabilities that are left are inherited by the root user inside the container when it gains the user ID 0 (in the given namespace created by clone(2)).

The scope of these capabilities are limited by the parameters passed to clone(2), which create new namespaces for various subsystems; cgroups; and any additional security subsystems, such as AppArmor or SELinux.

9
  • Thank you. Very good explanation. Docker doesn't create a new user namespace using clone(2) does it? I have read some documentation that it's possible to use user namespaces with Docker, but you first need to define various mappings etc.
    – Shuzheng
    May 29, 2020 at 9:37
  • Maybe you should rephrase this: "When Docker drops capabilities from the bounding set for the container, those capabilities are dropped for the the container" - I guess it's the thread of the docker process that drops capabilities before starting the cointainer.
    – Shuzheng
    May 29, 2020 at 9:41
  • The root user doesn't "gain" the UID 0 - it has that UID by definition :)
    – Shuzheng
    May 29, 2020 at 9:50
  • What exactly do you mean by "affecting the root user and all other users which are descendants from the process."?
    – Shuzheng
    May 29, 2020 at 9:55
  • Docker does indeed create new namespaces with clone(2) because it's required by the OCI spec. Not doing so would make the container trivially insecure. User namespaces as described in the documentation are the remapping of user IDs, not the creation of new namespaces with clone(2). As for your question, I've rephrased to make it clearer.
    – bk2204
    May 29, 2020 at 20:10
1

I think you're supposed to read the whole of the first paragraph as a description of the "old way", and the second as a description of how things currently stand (for the last 21 or so years).

For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: [...] Privileged processes bypass all kernel permission checks

Starting with kernel 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. Capabilities are a per-thread attribute.

2
  • would that mean the process, for the given capabilities only, bypasses relevant permission checks?
    – stdout
    Mar 11, 2021 at 13:54
  • 1
    @stdout, If I understand your question right, yes. I.e. if a process has CAP_DAC_READ_SEARCH, it bypasses the regular permission checks when reading files. But not when writing (that would be CAP_DAC_OVERRIDE). And the process doesn't need to have UID == 0 to have any of those caps. I think the man page is an ok resource man7.org/linux/man-pages/man7/capabilities.7.html, and there's also some description in the capabilities tag wiki: unix.stackexchange.com/tags/capabilities/info
    – ilkkachu
    Mar 11, 2021 at 14:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .