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

Colleagues, in the first part of the article about SElinux, we examined the main features of working with the SELinux system. As promised, we are now publishing the second part, which focuses on setting up policies. Well, let's get started.

Customizing SELinux Policies

Minor changes to SELinux policies can be made without completely changing the policy itself. To do this, it is enough to modify the logical values ​​associated with additional functions defined in the policy. These functions allow, for example, to provide access to user home directories using Samba or to allow Apache to use files located in the home directory.

By default, these features are disabled. The list of these functions is predetermined and consists of the most frequently used tasks facing the system administrator.

In order to view all the functions available for your system, just run the following command:

# getsebool -a

In order to change a parameter, you need to use the setsebool command. For example, in order to allow modules and scripts of the HTTPD service to connect to the network, just enter the following in the console:

# setsebool -P httpd_can_network_connect on

Creating custom policies with audit2allow

Sometimes situations arise when there are not enough predefined functions, when you need to supplement an existing policy with a new module, manually writing down certain conditions for granting access to something. For example, we install the Postgrey add-on for our SMTP mail server. Our server should interact with Postgrey through Unix sockets, but the standard SELinux policy for the mail server does not allow this, it blocks attempts to communicate through sockets.

In such situations, changing the context of the files will not help, there are no additional functions, including which we could fix the situation. Of course, you can always disable SELinux for a “problematic” service, but this solution, of course, is far from ideal, because there is a non-zero probability that the mail server will one day be hacked.

So, put SELinux in Permissive mode, and then start the mail server. After some time, AVC messages will appear in the SELinux log, in which all invalid actions of our server will be recorded:

type=AVC msg=audit(1218128130.653:334): avc:  denied  { connectto } for  pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket"
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1218128130.653:334): avc:  denied  { write } for  pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file 

Now we can use the audit2allow utility to generate a set of rules for the local policy that allows all the necessary Postgrey actions:

# grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te
# cat postgreylocal.te
module postgreylocal 1.0;
require {
        type postfix_smtpd_t;
        type postfix_spool_t;
        type initrc_t;
        class sock_file write;
        class unix_stream_socket connectto;
}
#============= postfix_smtpd_t ==============
allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
allow postfix_smtpd_t postfix_spool_t:sock_file write; 

So, we see that the audit.log file is filtered, from which all invalid actions performed by Postgrey, from the point of view of the current SELinux policy, are extracted. After reviewing these steps, we see that the SMTP server is trying to create a connection using a Unix socket, and Postgrey is trying to listen to this socket. It seems quite logical to take this information and create on its basis a user module for SELinux policy that would allow these actions:

# grep smtpd_t /var/log/audit/audit.log | audit2allow -M postgreylocal 

Now we need to load this module, adding to it the already involved policies with the semodule command:

# semodule -i postgreylocal.pp 

After that, the module is moved to /etc/selinux/targeted/modules/active/modules/postgreylocal.pp.
In order to check whether a module is loaded correctly, a list of all loaded modules can be displayed using the “semodule -l” command.

After that, we can continue to monitor SELinux to ensure that our newly created policy does not restrict Postgrey. As soon as we are satisfied and confident in the correct operation of the policy, we can activate Enforcing mode again, in full confidence that now our mail server is reliably protected and, at the same time, fully functioning.

Manual configuration of modules for SELinux policies.

Adit2allow, without a doubt, does a great job of creating models for policies that solve a particular problem. But sometimes this utility does not work quite right, so you have to configure the module manually. For example, consider SELinux AVC log entries:

Summary:
SELinux is preventing postdrop (postfix_postdrop_t) "getattr" to
/var/log/httpd/error_log (httpd_log_t).
Detailed Description:
SELinux denied access requested by postdrop. It is not expected that this access
is required by postdrop and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for /var/log/httpd/error_log,
restorecon -v '/var/log/httpd/error_log'
If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Context                system_u:system_r:postfix_postdrop_t
Target Context                root:object_r:httpd_log_t
Target Objects                /var/log/httpd/error_log [ file ]
Source                        postdrop
Source Path                   /usr/sbin/postdrop
Port                          
Host                          sanitized
Source RPM Packages           postfix-2.3.3-2
Target RPM Packages
Policy RPM                    selinux-policy-2.4.6-137.1.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     sanitized
Platform                      Linux sanitized 2.6.18-53.1.21.el5 #1 SMP Tue
                              May 20 09:35:07 EDT 2008 x86_64 x86_64
Alert Count                   599
First Seen                    Wed Jul  2 08:27:15 2008
Last Seen                     Sun Aug 10 22:47:52 2008
Local ID                      c303a4ea-8e7a-4acc-9118-9cc61c6a2ec8
Line Numbers
Raw Audit Messages
host=sanitized type=AVC msg=audit(1218397672.372:352): avc:  denied  { getattr } for  pid=4262 comm="postdrop"
path="/var/log/httpd/error_log" dev=md2 ino=117005 scontext=system_u:system_r:postfix_postdrop_t:s0
tcontext=root:object_r:httpd_log_t:s0 tclass=file
host=sanitized type=SYSCALL msg=audit(1218397672.372:352): arch=c000003e syscall=5 success=no exit=-13 a0=2
a1=7fffd6febca0 a2=7fffd6febca0 a3=0 items=0 ppid=4261 pid=4262 auid=4294967295 uid=48 gid=48 euid=48 suid=48
fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) comm="postdrop" exe="/usr/sbin/postdrop"
subj=system_u:system_r:postfix_postdrop_t:s0 key=(null) 

After we run audit2allow and look at the resulting postfixlocal.te policy, we will see the following:

# grep postdrop /var/log/audit/audit.log | audit2allow -M postfixlocal
# cat postfixlocal.te
    module postfixlocal 1.0;
    require {
            type httpd_log_t;
            type postfix_postdrop_t;
            class dir getattr;
            class file { read getattr };
    }
    #============= postfix_postdrop_t ==============
    allow postfix_postdrop_t httpd_log_t:file getattr; 

The question immediately arises, why is PostDrop trying to access / var / log / httpd / error_log? This is not the action that we could expect from this program, so now it is up to us to decide whether to allow this action or not.

We have several ways to solve this problem.

- We can ignore this error and allow SELinux to block access to the file.

“We can enable this action by creating an appropriate policy module using audit2allow.”
- We can manually edit the file of this module to determine the desired SELinux response to an attempt to access the file. For example, we can prohibit the audit of this event, while blocking access. To do this, we must change the "allow" value in the corresponding line to "dontaudit":

#============= postfix_postdrop_t ==============
dontaudit postfix_postdrop_t httpd_log_t:file getattr;

Now we have to manually compile and download the edited policy module:

# checkmodule -M -m -o postfixlocal.mod postfixlocal.te
# semodule_package -o postfixlocal.pp -m postfixlocal.mod
# semodule -i postfixlocal.pp 

Thus, access to the file / var / log / httpd / error_log is blocked, but we do not receive constant warnings about this from SELinux.

Actually, for SELinux, that's all for now, and in subsequent articles we will consider such an interesting (and hopefully useful) topic as disk quotas in linux for rpm distributions. A new article will be published on Monday.