Detailed explanation of Linux Namespace User

User namespace is a new namespace added in Linux 3.8, which is used to isolate security-related resources, including user IDs and group IDs, keys, and capabilities. The user ID and group ID of the same user can be different in different user namespaces (similar to the PID namespace). In other words, a user can be a normal user in one user namespace, but a superuser in another user namespace.

User namespaces can be nested (currently the kernel controls up to 32 layers). Except for the system default user namespace, all user namespaces have a parent user namespace, and each user namespace can have zero or more child user namespaces. When unshare or clone is called in a process to create a new user namespace, the original user namespace of the current process is the parent user namespace, and the new user namespace is the child user namespace.

Note: The demonstration environment of this article is Ubuntu 16.04.

Create a user namespace

We can create a new user namespace by using the --user option of the unshare command:

$ unshare -user -r /bin/bash 

Through the -r parameter, we map the root user in the new user namespace to the external nick user (the concepts related to mapping will be introduced next). In the new user namespace, the root user has the authority to create other namespaces, such as the uts namespace. This is because the current bash process has all capabilities:

Let's create a new uts namespace and try it out:

$ unshare --uts /bin/bash 

We can see that the new uts namespace has been successfully created. This is because, except for user namespace, creating other types of namespaces requires the CAP_SYS_ADMIN capability. After the new user namespace is created and the uid and gid are mapped, the first process of this user namespace will have all the complete capabilities, which means it can create new namespaces of other types.

In fact, there is no need to split the above operation (creating two namespaces) into two steps. We can create multiple namespaces at once by unshare:

In the implementation of unshare, CLONE_NEWUSER | CLONE_NEWUTS is actually passed in, which is roughly as follows:

unshare(CLONE_NEWUSER | CLONE_NEWUTS);

In the above case, the kernel will ensure that CLONE_NEWUSER is executed first, and then execute the remaining CLONE_NEW*, which makes it possible to create a new container without using the root user. This rule also applies to the clone function.

Understanding UID and GID mapping

In the previous demonstration, we mentioned the mapping of users between user namespaces. Now let's use the same demonstration to understand what the mapping is. Let's first check the current user's ID and user namespace:

Then execute the unshare --user /bin/bash command to create a new user namespace. Note that there is no -r parameter this time:

$ unshare --user /bin/bash 

In the new user namespace, the current user becomes nobody and the ID becomes 65534.

This is because we have not yet mapped the user ID and group ID of the parent user namespace to the child user namespace. This step is necessary so that the system can control the permissions of users in one user namespace in other user namespaces (such as sending signals to processes in other user namespaces, or accessing files mounted in other user namespaces).

If there is no mapping, when getuid() and getgid() are used to obtain the user ID and group ID in the new user namespace, the system returns the user ID defined in the file /proc/sys/kernel/overflowuid and the group ID defined in proc/sys/kernel/overflowgid, both of which have a default value of 65534. That is to say, if no mapping is specified, the ID will be mapped to 65534 by default.

Next, we complete the mapping of the nick user in the new user namespace.

The method of mapping IDs is to add mapping information to the /proc/PID/uid_map and /proc/PID/gid_map files (where PID is the process ID in the new user namespace, and both files are empty at the beginning). The format of the configuration information in these two files is as follows (each file can contain multiple configuration information):

ID-inside-ns ID-outside-ns length

For example, the configuration 0 1000 500 means that 1000~1500 in the parent user namespace is mapped to 0~500 in the new user namespace.

There is a strict permission control on the writing operation of uid_map and gid_map files. To put it simply: the owner of these two files is the user who creates the new user namespace, so the root account in the same user namespace as this user can write to them; whether this user has the permission to write to the map file depends on whether he has the CAP_SETUID and CAP_SETGID capabilities. Note: You can only write data to a map file once, but you can write multiple entries at a time, and the maximum number of entries is 5.

We call the shell window just opened the first shell window and start to execute the user mapping operation (map user nick to root in the new user namespace).

The first step is to check the ID of the current process in the first shell window:

The second step is to open a new shell window, which I call the second shell window. View the mapping file properties of process 3049:

User nick is the owner of these two files. Let's try to write mapping information to these two files:

It seems strange that I am the owner of the file, but I don’t have permission to write to the file! In fact, the fundamental reason is that the current bash process does not have CAP_SETUID and CAP_SETGID permissions:

Next we set the relevant capabilities for the /bin/bash program:

$ sudo setcap cap_setgid,cap_setuid+ep /bin/bash

Then reload bash and you will see the corresponding capabilities:

Now rewrite the mapping information to the map file:

$ echo '0 1000 500' > /proc/3049/uid_map
$ echo '0 1000 500' > /proc/3049/gid_map

This time the write was successful. We don't need to manually write the mapping information later, so we restore the capability of /bin/bash to its original setting through the following command:

$ sudo setcap cap_setgid,cap_setuid-ep /bin/bash 

Step 3: Return to the first shell window

Reload bash and execute the id command:

The current user has become root (the root user in the new user namespace). Let's take a look at the capabilities of the current bash process:

0000003fffffffff means that the currently running bash has all capabilities.

Step 4. In the first shell window

Check the access permissions of the /root directory:

No permission! Try changing the host name:

Still no permission! It seems that the root user in this new user namespace does not work in the parent user namespace. This is exactly the effect that user namespaces expect to achieve. When accessing resources in other user namespaces, the permissions are used to execute the access. For example, the user corresponding to the parent user namespace for root is nick, so the hostname of the system cannot be changed.

Ordinary user nick does not have permission to modify the hostname. Then, after mapping the root user in the default user namespace to the root user in the sub-user namespace, can the hostname be modified? The answer is no! That is because no matter how the mapping is performed, when a user in a child user namespace accesses resources in a parent user namespace, the capability of the process it starts is empty, so the root user in the child user namespace is equivalent to an ordinary user in the parent user namespace.

Relationship between User namespace and other namespaces

Each namespace under Linux is associated with a user namespace. This user namespace is the user namespace to which the process belongs when the corresponding namespace is created. This is equivalent to each namespace having an owner (user namespace). This ensures that operations on any namespace are controlled by the user namespace permissions. This is also why setting the hostname in the child user namespace fails, because the uts namespace to be modified belongs to the parent user namespace, and the processes in the new user namespace do not have any capabilities of the old user namespace.

Taking uts namespace as an example, there is a pointer to user namespace in the uts_namespace structure, which points to the user namespace to which it belongs (in the v4.13 kernel I checked, the definition of uts_namespace structure is in the /include/linux/utsname.h file):

The definitions of other namespaces are similar.

Summarize

Compared with other namespaces, user namespace is slightly more complicated. This is due to its functionality, and when it comes to permissions management, things tend to be less intuitive. In this article, I have only introduced the basic concept of user namespace. There are more interesting contents waiting for you to discover.

refer to:

user namespace man page
Namespaces in operation, part 5: User namespaces
Namespaces in operation, part 6: more on user namespaces
Linux capabilities

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.