This is the second article in the series.

Today we will talk about SELinux-users, their creation, binding, rights and other things.
Why do this? There are many reasons. For me, the main reason was to issue access for technical support for routine operations (such as reboot, cleaning logs, diagnostics, etc.), but without access to critical data and changes in system functions.
Assumptions
The text will contain a lot of technical information, so the author assumes that the reader:
')
- Read the last article
- Has on hand CentOS 7
- On which the packages setools-console, policycoreutils-devel, selinux-policy-devel, policycoreutils-newrole are installed
- And SELinux is enabled in enforcing mode with a targeted or minimum policy
Is this all about you? Then let's go!
Users and Roles
The main purpose of users is to keep a list of roles that they can use.
The default users are already represented in the policy of targeted or minimum, you can see the
semanage user -l command .

As is known from the previous article, it is the
roles that are containers for
types , namely, all necessary rules are hung on types.
Thus, the user simply expands this tree, creating more options. Note: if a user has one or another role, he can switch to it himself, using the
newrole command. Thus, by allowing the user the sysadm_r or unconfined_r role, you automatically give him unlimited rights to the system.
Users and Users
There is a fine connection between the Unix user (the one that has the UID) and the SELinux user (the one that has the context), which can be controlled using the
semanage login command . The connection is one-way: id -Z user1 will not show you anything. The special user
__default__ denotes all users not listed in the system.

Create user (easy way)
The easiest way to create a user from ready-made roles is to use
semanage user -a .
Suppose we just need a new user with an additional set of roles:

So we got a user who has the ability to adminit the web. Now we can set a user for it:

Context
About this in few places they write, but it is not enough just to create a user. If its context is different from
default_context , it is necessary to configure the context file for it. For details, see
man user_contexts .
Configure the file for webadm_u:

Check
Log in as webadm user:

Change the uid to 0 and try to break something:

Change the role to webadm_r and try now:

What was required to prove - we did the admin, which can adminit only the web. Unfortunately, the number of roles by default is very limited. The list can be found
here .
Create user (correct way)
Let's do the same thing, but for example to administer
docker , and write it from scratch.
The module will be very simple. What do we need to allow?
- Ssh login
- Access to sudo (UNIX-rights have not been canceled) *
- Administration of files, folders and docker services
- Execution of docker binaries (docker, runcon)
- Connect to dock socket
*The docker group on the latest version of CentOS7 does not have access to /run/docker.sock by default.
Write the module and context file:
# policy_module(dockeradm, 1.0.3) # role dockeradm_r; # - userdom_unpriv_user_template(dockeradm) # dac_override allow dockeradm_t self:capability { dac_override dac_read_search }; # sudo sudo_role_template(dockeradm, dockeradm_r, dockeradm_t) # container_admin(dockeradm_t) # container_runtime_exec(dockeradm_t) # container_stream_connect(dockeradm_t) # gen_user -, semanage user -a # gen_user(dockeradm_u, dockeradm, dockeradm_r, s0, s0)
Compile and install the module:

Set user and context:

Let's check what lets us into the system:

Check our rights:

As Apache says,
It works!Summarizing
Creating SELinux users is an important step towards creating a full-fledged working environment in which each employee does his own work and does not interfere with others. Whether it is a hosting provider, a development studio or a bank, there are always situations when access sharing is necessary. Turn on SELinux and enjoy :)