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

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

Customizing SELinux Policies

')

Minor changes in SELinux policies can be carried out without completely changing the policy itself. To do this, it suffices to modify the logical values ​​associated with the additional functions defined in the policy. These functions allow, for example, to provide access to users' 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 predefined and consists of the most frequently used tasks faced by the system administrator.



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

# getsebool -a 

In order to change any parameter, you need to use the setsebool command. For example, in order to allow HTTPD modules and scripts 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 there are situations when there are not enough predefined functions, when you need to supplement an existing policy with a new module, manually specifying 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 via Unix-sockets, but the standard SELinux policy for the mail server does not allow this, blocking attempts to communicate through sockets.



In such situations, changing the context of files will not help; there are no additional functions; by including them, we could correct the situation. Of course, you can always turn off SELinux for the “problem” service, but this solution, of course, is far from ideal, because there is a non-zero probability that the mail server will be hacked sometime.



So, we will translate SELinux into Permissive mode, then we will start the mail server. After some time, AVC-messages will appear in the SELinux log, in which all unacceptable 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 a local policy that permits 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, from the point of view of the current SELinux policy, actions produced by Postgrey are extracted. After reviewing these actions, we see that the SMTP server is trying to create a connection using a Unix-socket, and Postgrey is trying to listen on this socket. It seems quite logical to take this information and create on its basis a custom module for the SELinux policy, which would allow these actions:

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

Now we have to load this module, adding to it the policies already involved 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 the module is loaded correctly, you can display a list of all loaded modules using the “semodule -l” command.



After that, we can continue to monitor the SELinux log to make sure that our newly created policy does not limit Postgrey. Once we are satisfied and confident in the correct operation of the policy, we can re-activate the Enforcing mode, in full confidence that our mail server is now securely protected and, at the same time, fully functional.

Manual configuration of modules for SELinux policies.

Adit2allow, no doubt, does an excellent job with creating models for policies that solve a particular problem. But sometimes this utility does not work quite correctly, so you have to configure the module manually. For example, consider the entries in the SELinux AVC log:

 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 <Unknown> 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 examine 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; 

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



We have several solutions to this problem.



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



- We can allow this action by creating the appropriate policy module with audit2allow.

“We can manually edit the file of this module to determine the SELinux response we need to attempt to access the file. For example, we can prohibit the audit of this event, blocking access at the same time. To do this, we need to change the value of “allow” in the corresponding line to “dontaudit”:

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

Now we need to manually compile and load 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 / var / log / httpd / error_log file is blocked, but we do not receive permanent warnings about this from SELinux.



Actually, for SELinux everything is so far, and in subsequent articles we will look at such an interesting (and hopefully useful) topic, like disk quotas in linux for rpm distributions. New article will be published on Monday.