Implement mandatory access control (MAC) with SELinux or AppArmor on Linux

To address the standard "user-group-other/read-write-execute" permissions, as well as restrictions on access control lists and enhanced security mechanisms, the National Security Agency (NSA) has designed a flexible access control (mandatory) method SELinux (Security enhanced Linux abbreviation), to restrict permissions beyond the standard permissions, allows the process to access as little as possible with minimal permissions or in system objects such as files, folders, and so on, while still allowing subsequent modifications to this control model Other operations on the network ports, etc.).

Another popular and widely used MAC is AppArmor, which offers more features than SELinux, including a learning model that allows the system to "learn" the behavior of a particular application, as well as the use of a secure application through configuration file settings restrictions.

In CentOS 7, SELinux is merged into the kernel and forced enforcing mode is enabled by default (more on this in the next section), unlike OpenSUSE and Ubuntu using AppArmor.

In this article we will explain the nature of SELinux and AppArmor, and how to use one of these two tools in your chosen distribution to benefit from it.

Introduction to SELinux and how to use it in CentOS 7

Security Enhanced Linux can run in two different modes:

• Force enforcing: In this case, SELinux denies access based on the SELinux policy rule, which is a set of rules that control the security engine.
• Tolerant permissive: In this case, SELinux does not deny access, but actions that are rejected in forced mode are logged.

SELinux can also be disabled. Although this is not one of its operating modes, it is also an option. But learning how to use this tool is better than just ignoring it. Always keep this in mind!

Use getenforce the command to display the current mode of SELinux. If you want to change the mode, use setenforce 0 (set to tolerant mode) or setenforce 1 (Force mode).

Since these settings fail after reboot, you will need to edit the /etc/selinux/config configuration file and set the SELINUX variable to enforcing , or, save the settings to restart it permissive disabled also works:

How to enable and disable SELinux mode

It is also important to note that if getenforce you return to Disabled, you have to edit the /etc/selinux/config configuration file for the mode of operation you want and reboot. Otherwise you cannot use the setenforce set (or toggle) mode of operation.

setenforceOne of the typical uses of this includes switching between SELinux modes (from coercion to tolerance or vice versa) to locate whether an app is misbehaving or not working as expected. If it works correctly when you set SELinux to tolerant mode, you can be sure that you are experiencing SELinux permissions issues.

There are two typical cases in which we may need to address the use of SELinux:

• Change the default port that a daemon listens to.
• Set a document root path value other than/var/www/html for a virtual host.

Let's take a look at both of these cases in the following example.

Example 1: Changing the default port of the sshd daemon

One of the first things that most system administrators need to do to secure server security is to change the ports that the SSH daemon listens to, primarily to prevent port scans and external attacks. To achieve this, we want to change /etc/ssh/sshd_config the port value in the following value (we use port 9999 here for example):

1. Port 9999

After attempting to restart the service and check its status, we will see that it failed to start:

1. # systemctl restart sshd
2. # systemctl status sshd

Check SSH service Status

If we look at it /var/log/audit/audit.log , we will see that sshd is blocked from starting on port 9999 because it is a reserved port for the JBoss Management Service (SELinux log information contains the word "AVC", so it should be easy to distinguish it from other information):

1. # cat /var/log/audit/audit.log | grep AVC | tail -1

Check the Linux audit log

In this scenario, most people may disable SELinux, but we do not. We'll see a way to let SELinux and the SSHD monitor other ports in harmony. First make sure you have policycoreutils-python this package, execute:

1. # yum install policycoreutils-python

View the list of ports that SELinux allows sshd to listen on. In the next picture we can also see that port 9999 is reserved for other services, so we can't use it to run other services for the time being:

1. # semanage port -l | grep ssh

Of course we can choose a different port for SSH, but if we're sure we won't use this machine to run any JBoss-related services, we can modify the rules that SELinux already exists and assign that port to SSH instead:

1. # semanage port -m -t ssh_port_t -p tcp 9999

After that, we can use the previous command to check that the semanage port is correctly assigned, i.e. using -lC the parameter (the name of the list custom):

1. # semanage port -lC
2. # semanage port -l | grep ssh

assigning Ports to SSH

We can now restart the SSH service and connect via port 9999. Note that this change is still valid after a reboot.

Example 2: Set a document root path other than/var/www/html for a virtual host DocumentRoot

If you need to /var/www/html set up an Apache virtual host (that is, for example) by using a directory other than directories as the document root DocumentRoot /websrv/sites/gabriel/public_html :

1. DocumentRoot “/websrv/sites/gabriel/public_html”

Apache will refuse to provide content because index.html it has been tagged for default_t SELinux the type, and Apache cannot access it:

1. # wget http://localhost/index.html
2. # ls -lZ /websrv/sites/gabriel/public_html/index.html

is marked as default_t SELinux type

As in the previous example, you can verify that this is a SELinux-related issue with the following command:

1. # cat /var/log/audit/audit.log | grep AVC | tail -1

Check logs to determine if SELinux is a problem

To /websrv/sites/gabriel/public_html mark the entire directory contents as httpd_sys_content_t , execute:

1. # semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

The above command gives Apache read access to that directory and its contents.

Finally, to apply this policy (and have the tag of the change take effect immediately), execute:

1. # restorecon -R -v /websrv/sites/gabriel/public_html

Now you should be able to access this directory:

1. # wget http://localhost/index.html

Access to the Apache directory

For more information about SELinux, refer to the SELinux user and Administrator's Guide in Fedora 22.

AppArmor introduction and how to use it on OpenSUSE and Ubuntu

The AppArmor operation is based on a rule definition written in a plain text file that contains permission and access control rules. A security profile is used to restrict how an application interacts with processes and files in the system.

The system initially provides a series of configuration files, but others can be set by the application at the time of installation or manually by the system administrator.

Like SELinux, AppArmor operates in two modes. In forced enforce mode, the app is given the minimum permissions that they need to run, but in complaining about complain mode AppArmor allows an app to perform restricted operations and record "complaints" from the operation into the log ( /var/log/kern.log , /var/log/audit/audit.log , and other /var/log/apparmor Log in).

The log shows a record that the configuration file will produce errors when it is run in forced mode, with audit the word in them. Therefore, you can try to run an app and adjust its behavior in the complaining complain mode before you run it in AppArmor's forced enforce mode.

You can use this command to display the current status of AppArmor:

1. $ sudo apparmor_status

View the status of AppArmor

The above picture indicates the configuration, /sbin/dhclient /usr/sbin/ and /usr/sbin/tcpdump is in force enforce mode (this is the default for Ubuntu).

Because not all applications contain the associated AppArmor configuration, the Apparmor-profiles package provides the configuration for other packages that do not provide a limit. By default they are configured to run in the complaining complain mode so that the system administrator can test and select a desired configuration.

We will use apparmor-profiles because writing a copy of our own configuration is beyond the scope of the LFCS certification. However, because the configurations are plain text files, you can view and learn them in preparation for creating your own configuration later.

The AppArmor configuration is saved in /etc/apparmor.d . Let's take a look at how this folder differs before and after installing Apparmor-profiles:

$ ls /etc/apparmor.d

View AppArmor Folder Contents

If you do sudo apparmor_status it again, you'll see a longer list of profiles in the complaining complain mode. You can now perform the following actions.

Switch the configuration file currently in force enforce mode to the complaining complain mode:

$ sudo aa-complain /path/to/file

and the opposite (complaining about –> coercion):

$ sudo aa-enforce /path/to/file

The above examples are allowed with wildcard characters. As an example:

$ sudo aa-complain /etc/apparmor.d/*

All of /etc/apparmor.d the profiles in will be set to complain about complain mode, whereas

$ sudo aa-enforce /etc/apparmor.d/*

All configuration files are set to force enforce mode.

To completely disable a configuration, /etc/apparmor.d/disabled create a symbolic link in the directory:

$ sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/

For more information about AppArmor, refer to the official AppArmor wiki and the documentation provided by Ubuntu.

Summarize

In this article we have learned some basic knowledge of the two well-known mandatory access control systems for SELinux and AppArmor. When do you use one of the two or the other? To avoid the difficulty, you might want to consider focusing on the one that comes with the distribution you choose. In any case, they will help you limit access to processes and system resources to improve the security of your servers.

Ding Feng Xiao Hu
qq.2881064155
[Email protected]

Implement mandatory access control (MAC) with SELinux or AppArmor on Linux