Shulou(Shulou.com)06/02 Report--

User namespace is a new namespace in Linux 3.8.It 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 namespace (similar to PID nanespace). In other words, a user can be a normal user in one user namespace, but a superuser in another user namespace.

User namespace can be nested (currently the kernel controls up to 32 layers). Except for the system default user namespace, all user namespace have a parent user namespace, and each user namespace can have zero to more than one child user namespace. When you call unshare or clone 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.

Description: the demo environment for this article is ubuntu 16.04.

Create user namespace

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

$unshare-user-r / bin/bash

With the-r parameter, we map root users in the new user namespace to external nick users (we'll introduce mapping-related concepts next). In the new user namespace, the root user has permission to create other namespace, such as uts namespace. This is because the current bash process has all the capabilities:

Let's try to create a new uts namespace:

$unshare-- uts / bin/bash

We see that the new uts namespace has been successfully created. This is because the capability of CAP_SYS_ADMIN is required to create all types of namespace except user namespace. When the new user namespace creates and maps uid and gid, the first process of the user namespace will have all the capabilities in its entirety, meaning it can create new other types of namespace.

In fact, there is no need to divide the above operation (creating two namespace) into two steps. We can create more than one namespace at a time through unshare:

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

Unshare (CLONE_NEWUSER | CLONE_NEWUTS)

In this case, the kernel ensures that the CLONE_NEWUSER is executed first, and then the rest of the CLONE_NEW*, is executed, which makes it possible to create a new container without the root user, and this rule also applies to the clone function.

Understand the mapping between UID and GID

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

Then execute the unshare-- user / bin/bash command to create a new user namespace, and notice 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, which is necessary because the system can control the permissions of users in one user namespace in other user namespace (such as sending signals to processes in other user namespace, or accessing files that belong to other user namespace mounts).

If there is no mapping, when you get user ID and group ID with getuid () and getgid () 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, if no mapping relationship is specified, ID will be mapped to 65534 by default.

Let's complete the mapping of nick users in the new user namespace.

The way to map ID is to add mapping information to / proc/PID/uid_map and / proc/PID/gid_map (where PID is the process ID in the new user namespace, both of which were empty at first). The format of the configuration information in these two files is as follows (there can be multiple pieces of configuration information in each file):

ID-inside-ns ID-outside-ns length

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

There are strict permissions to write uid_map and gid_map files, to put it simply: the owner of these two files is the user who created the new user namespace, so the root account in the same user namespace with this user can be written; whether the user has the permission to write map files depends on whether it has CAP_SETUID and CAP_SETGID capability. Note: you can only write data to the map file once, but you can write more than one item at a time, and a maximum of 5 entries can be written.

Let's call the shell window we just opened the first shell window to start the user's mapping operation (mapping the user's nick to the root in the new user namespace).

The first step is to view 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 for process 3049:

User nick is the owner of these two files, so let's try to write mapping information to both files:

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

Let's set up the relevant capabilities for the / bin/bash program:

The copy code is as follows: $sudo setcap cap_setgid,cap_setuid+ep / bin/bash

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

Then reload bash, and you can 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

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

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

Step 3, go back 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). Take a look at the capability that the current bash process has:

0000003fffffffff indicates that the currently running bash has all the capability.

Step 4, in the first shell window

View the access permissions of the / root directory:

I don't have permission! Try to modify the name of the host:

There is still no authority! It seems that the root user in this new user namespace doesn't work well in the parent user namespace. This is exactly what user namespace expects to achieve. When accessing resources in other user namespace, it is executed with the permissions of the corresponding user in other user namespace. For example, the user of root corresponding to the parent user namespace is nick, so the hostname of the system cannot be changed.

The ordinary user nick does not have the permission to modify hostname, so can you modify hostname after mapping the root user in the default user namespace to the root user in the child user namespace? The answer is no! That's because no matter how it is mapped, when the user of the child user namespace accesses the resource of the parent user namespace, the capability of the process it starts is empty, so the root user of the child user namespace here is equivalent to a normal user in the parent user namespace.

The relationship between User namespace and other namespace

Each namespace under Linux has a user namespace associated with it. This user namespace is the user namespace to which the process belongs when the corresponding namespace is created, which is equivalent to an owner (user namespace) for each namespace, which ensures that the operation on any namespace is controlled by user namespace permissions. This is why it failed to set hostname in the child user namespace, because the uts namespace to be modified belongs to the parent user namespace, and the process of the new user namespace does not have any capabilities of the old user namespace.

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

Other definitions of namespace are similar.

Summary

Compared with other namespace, user namespace is a little more complex. This is determined by its function, and things tend to become less intuitive when it comes to the content of rights management. In this article, the author only introduces the basic concept of user namespace, and more rich and interesting content remains to be explored.

Reference:

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 whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.