SELinux - description and features of working with the system. Part 1

About SELinux on Habré already wrote, however, not so much detailed manuals on this system are published. Today we publish just such a detailed manual on SELinux, starting from information on the system, and ending with flexible policy settings.
In order not to turn the post into a “sheet” that is difficult to understand, we decided to divide the manual into two parts. The first will be about the system itself, and some of its features. The second is about setting policies. Now we are publishing the first part, and the second part will be published a little later.

1. Introduction

')
SELinux (SELinux) is a compulsory access control system implemented at the kernel level. For the first time this system appeared in the fourth version of CentOS, and in versions 5 and 6, the implementation was significantly augmented and improved. These improvements have allowed SELinux to become a universal system capable of effectively solving a lot of current tasks. It is worth remembering that the classic Unix rights system is applied first, and the control will pass to SELinux only if this initial check is successfully passed.

1.1 Some current tasks.

In order to understand the practical value of SELinux, consider a few examples when the standard access control system is insufficient. If SELinux is disabled, then only the classical discretionary access control system is available, which includes DAC (selective access control) or ACL (access control lists). That is, we are talking about manipulating the rights to write, read and execute at the level of users and groups of users, which in some cases may be completely inadequate. For example:

- The administrator can not fully control user actions. For example, a user is fully capable of giving all other users the right to read their own confidential files, such as SSH keys.

- Processes may change security settings. For example, files containing the user's mail should be readable only by one specific user, but the mail client may well change the access rights so that these files are readable by everyone.

- Processes inherit the rights of the user who launched them. For example, a Trojan-infected version of the Firefox browser is able to read the user's SSH keys, although it has no reason to do so.

In fact, in the traditional model of selective access control (DAC), only two levels of access are well implemented - the user and the superuser. There is no simple method that would allow each user to set the required minimum of privileges.
Of course, there are many ways to circumvent these problems within the framework of the classical security model, but none of them is universal.

1.1.1 Basic terms used in SELinux:

Domain - a list of actions that a process can perform. Usually, the minimum possible set of actions by which a process is able to function is defined as a domain. Thus, if the process is discredited, the attacker will not be able to do much harm.

Role - a list of domains that can be applied. If a domain is not in the list of domains of a role, then the actions from this domain cannot be applied.

Type - a set of actions that are valid in relation to the object. The type is different from the domain in that it can be applied to pipes, directories and files, while the domain is applied to processes.

Security context — all SELinux attributes — roles, types, and domains.

1.2 Solving the problems of the traditional security model.

SELinux follows the model of the minimum necessary privileges for each service, user and program much more strictly. The default setting is “prohibitory mode”, when each element of the system has only those rights that are vital for its operation. If the user, program or service tries to change the file or access the resource, which is clearly not necessary to solve them, they will simply be denied access, and such an attempt will be recorded in the log.



SELinux is implemented at the kernel level, so applications can be completely unaware of the version of this system of forced access control, the features of its operation, etc. In the case of proper configuration, SELinux will not affect the functioning of third-party programs and services. Although, if the application is capable of intercepting the error messages of this access control system, the usability of the application is significantly increased. Indeed, in the case of an attempt to access a protected resource or file, SELinux sends to the main application an error from the access denied family. But only a few applications use the system call codes received from SELinux.

Here are some examples of using SELinux that allow you to see how you can increase the security of the entire system.

- Creating and configuring a list of programs that can read ssh-keys.

- Prevent unauthorized access to data through the mail-client.

- Configure the browser so that it can read in the user's home folder only the necessary files and folders for operation.

2. SELinux modes of operation

SELinux has three main modes of operation, while the default mode is Enforcing. This is a fairly hard mode, and if necessary, it can be changed to more convenient for the end user.

Enforcing : The default mode. When this mode is selected, all actions that somehow violate the current security policy will be blocked, and the violation attempt will be recorded in a log.

Permissive : In the case of using this mode, information on all actions that violate the current security policy will be recorded in the log, but the actions themselves will not be blocked.

Disabled : Completely disable the forced access control system.

You can view the current mode and other SELinux settings (and, if necessary, change it) using a special GUI tool available in the “Administration” menu (system-config-selinux). If you are used to working in the console, you can see the current status with the sestatus command.

# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted 

You can also find out the status of SELinux with the getenforce command.
The “setenforce” command allows you to quickly switch between Enforcing and Permissive modes, the changes take effect without rebooting. But if you enable or disable SELinux, a reboot is required, because you need to reinstall the security labels in the file system.
In order to select the default mode that will be used each time the system is booted, set the value of the 'SELINUX =' line in the / etc / selinux / config file, specifying one of the modes - 'enforcing', 'permissive' or 'disabled' . For example: 'SELINUX = permissive'.

3. SELinux policies

As noted earlier, SELinux, by default, works in Enforcing mode, when any actions other than those allowed are automatically blocked, each program, user, or service has only those privileges that they need to function, but nothing more. This is a fairly tough policy, which has both advantages - the highest level of information security, and minuses - configuring the system in this mode is associated with large labor costs for system administrators, and there is also a high risk that users will face access restrictions if they want to use the system at least in a non-trivial way. This approach is valid in the enterprise sector, but is unacceptable on end-user computers. Many administrators simply disable SELinux on workstations so as not to encounter such problems.



In order to avoid this, for key applications and services, such as, for example, httpd, named, dhcpd, mysqld, pre-configured target policies are defined that prevent the attacker from gaining access to sensitive data. The same applications for which the policy is not defined run in the unconfined_t domain and are not protected by SELinux. Thus, properly selected target policies allow you to achieve an acceptable level of security without creating unnecessary problems for the user.

4. Access control in SELinux

SELinux provides the following access control models:

Type Enforcement (TE): The main access control mechanism used in targeted policies. Allows detailed, at the lowest level to manage permissions. The most flexible, but also the most time-consuming mechanism for the system administrator.

Role-Based Access Control (RBAC): in this model, access rights are implemented as roles. The role is the permission to perform certain actions by one or more elements of the system on other parts of the system. In essence, RBAC is a further development of TE.

Multi-Level Security (MLS): a multi-level security model, in which all objects of the system are assigned a certain level of access. Allowing or denying access is determined only by the ratio of these levels.

All processes and files within SELinux have a security context.
Let's look at the context in practice, having examined in detail the start page of the Apache web server, located at /var/www/html/index.html

 $ ls -Z /var/www/html/index.html -rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html 

In addition to the standard file permissions, we can see the SELinux security context: system_u: object_r: httpd_sys_content_t.

The context is based on user: role: type: mls, but user: role: type fields are displayed while the mls field is hidden. We can also see the target policy, in this case httpd_sys_content_t.

Now consider the SELinux security context for the 'httpd' process (Apache web server):

 $ ps axZ | grep httpd system_u:system_r:httpd_t 3234 ? Ss 0:00 /usr/sbin/httpd 

As we can see, this process is running on the httpd_t domain.

Well, now let's look at the security context of the file in our home directory:

 $ ls -Z /home/username/myfile.txt -rw-r--r-- username username user_u:object_r:user_home_t /home/username/myfile.txt 

We see that the file is of type user_home_t, this type is assigned by default to all files in the home directory.
Access is allowed only between elements with the same type, which is why the Apache web server can easily read the file /var/www/html/index.html, which has the type httpd_sys_content_t. At the same time, since Apache is running on the httpd_t domain and does not have filled userid: username fields, it cannot access the home / username / myfile.txt file, although this file is available for reading to processes for which the target is not defined. politics. Thus, if the Apache web server is hacked, the attacker will not be able to access files or run processes that are not in the httpd_t domain.

5. Troubleshooting SELinux

Sooner or later, a situation occurs when you encounter a situation where SELinux denies you access to something. There are several main reasons for access denial:

- Incorrectly labeled file.
- The process works in the wrong context.
- Error in policy. The process requires access to a file that was not considered when creating the policy.
- Attempt to invade.

The first three reasons for denying access are resolved quite easily, while an alarm sounds during an intrusion attempt and a notification is sent to the user.
In order to deal with any problem, just look through the SELinux log. By default, it is recorded by the auditd process in the /var/log/audit/audit.log file. If this process is not running, then SELinux logs in the / var / log / messages file, in this case, all access control messages are marked with the AVC key, which allows you to quickly filter the necessary lines, for example. using the grep command.
In the latest versions of distributions (starting with CentOS 5), a utility with a graphical user interface is included, which allows you to display the SELinux magazine in a convenient and user-friendly way. You can call it from the console by typing sealert -b. The utility is part of the package setroubleshoot. In the event that the X server is not running, you can generate clear and user-friendly reports with the following command:

 sealert -a /var/log/audit/audit.log > /path/to/mylogfile.txt 

5.1 Changing the security context labels of files.

The “chcon” command allows you to change the SELinux context for files or directories in exactly the same way as the “chown” and “chmod” commands allow you to change the owner of the file or access rights to it within the standard access control system.



Consider a few examples.
Suppose that the Apache web server is installed on the system and we need to change the folder in which the sites are stored (by default, this is / var / www / html /) to, say, / html / and create the index.html file in this directory.

 # mkdir /html # touch /html/index.html # ls -Z /html/index.html -rw-r--r-- root root user_u:object_r:default_t /html/index.html # ls -Z | grep html drwxr-xr-x root root user_u:object_r:default_t html 

Above, we see that both the / html directory and the /html/index.html file, within the security context, have the type default_t. This means that if we start Apache and try to start working with this directory or file, SELinux will refuse to give us access. And it will be absolutely correct, because the correct security context for files interacting with Apache is httpd_sys_content_t.
Change the context and check if everything is done correctly:

 # chcon -v --type=httpd_sys_content_t /html context of /html changed to user_u:object_r:httpd_sys_content_t # chcon -v --type=httpd_sys_content_t /html/index.html context of /html/index.html changed to user_u:object_r:httpd_sys_content_t # ls -Z /html/index.html -rw-r--r-- root root user_u:object_r:httpd_sys_content_t /html/index.html # ls -Z | grep html drwxr-xr-x root root user_u:object_r:httpd_sys_content_t html 

It is not necessary to manually process each file and each directory; you can simply use the recursive directory traversal option -R:

 # chcon -Rv --type=httpd_sys_content_t /html 

Such changes to the security context will persist between reboots, however, if the file system labels change, the changes will disappear. In the process of maintenance and operation, this is not uncommon. The correct solution in such a situation would be (after testing, of course) to create an additional rule, and then merge it with local local rules. Thus, it will have a higher priority than the basic rules.

In order for SELinux to work correctly even after changing file system labels, we can use both SELinux control tools with a GUI interface and the semanage console utility:

 semanage fcontext -a -t httpd_sys_content_t "/html(/.*)?" 

In the example above, we assigned the httpd_sys_content_t context to all files in the / html directory.

5.2 Restoring the SELinux Security Context.

The “restorecon” command allows you to change the security context to the one that was assigned by default.
Again, use the Apache web server as an example. Suppose that a user edited a copy of the index.html file in his home directory and moved it (using the mv command) to the directory in which the websites were stored (/ var / www / html).

Note that when copying (cp command), the security context of the file will match the context of the destination directory, while moving, the security context will match the source context. Of course, we could use the chcon command to change the security context, but since the moved files are now in the / var / www / html directory, we can simply restore the context settings for all the files in that directory.

In order to restore the context only for the index.html file, we can use the command:

 # restorecon -v /var/www/html/index.html 

If we want to recursively go around the entire directory and change the context for all the files it contains, use the following command:

 # restorecon -Rv /var/www/html 

5.3 Changing labels for the entire file system.

Sometimes it is necessary to reinstall security labels in the entire file system. Most often, such an operation is performed when SELinux is re-enabled, after the system has been turned off for a while. It is also necessary if we change the type of policy management to strict (in this case, all processes work in their special domains, no one can work in the unconfined_t domain).

In order to automatically re-partition the file system upon the next reboot, enter the following commands:

 # touch /.autorelabel # reboot 

Sometimes automatic redevelopment does not work (most often in cases where the distribution with the SELinux system turned off has been updated). In this case, use the following command:

 # genhomedircon # touch /.autorelabel # reboot 

5.4 Providing access to ports.

Often we want services like Apache to be able to listen on non-standard ports and accept incoming connections to them. Basic SELinux policies allow you to access only predefined ports that are tightly connected to a particular service. Suppose we want Apache to listen on port 81. In this case, we need to add a rule using the semanage command:

 # semanage port -a -t http_port_t -p tcp 81 

A complete list of ports that SELinux provides access to can be viewed as follows:

 # semanage port -l 

In the next, second part of the manual, we will show the possibility of flexible configuration of system policies.