SElinux Rules

There are various rules defined in an SELinux policy. To view them, use the seinfo command discussed earlier.

[root@vbg ~]# seinfo

Statistics for policy file: /etc/selinux/targeted/policy/policy.21
Policy Version & Type: v.21 (binary, MLS)

   Classes:            61      Permissions:       220
   Types:            1514      Attributes:        148
   Users:               3      Roles:               6
   Booleans:          211     Cond. Expr.:       187
   Sensitivities:       1      Categories:       1024
   Allow:           82576      Neverallow:          0
   Auditallow:         28      Dontaudit:        5086
   Role allow:          5      Role trans:          0
   Type_trans:       1399      Type_change:        17
   Type_member:         0      Range_trans:        23
   Constraints:        47      Validatetrans:       0
   Fs_use:             15      Genfscon:           64
   Portcon:           264      Netifcon:            0
   Nodecon:             8      Initial SIDs:       27

Text formatted in bold in the above output represents the information section on rules. As we can see, the default policy loaded in my system has:

• 82,756 Allow Rules
• 1,399 Type Transition Rules
• 5,086 Don’t Audit Rules, and so on.

To view these rules and get an understanding of how they work, let us explore the sesearch command.

[root@vbg ~]# sesearch -a

Found 87690 av rules:
   allow bluetooth_helper_tmp_t bluetooth_helper_tmp_t : filesystem associate ;
   allow httpd_bugzilla_script_t httpd_bugzilla_script_t : lnk_file { ioctl read getattr lock };
   allow avahi_t avahi_t : fifo_file { read write };
   allow avahi_t avahi_t : tcp_socket { ioctl read write create getattr setattr append bind connect listen accept getopt setopt shutdown };
   allow aide_t newrole_t : fd use ;

The sesearch command allows us to query a policy for Type Enforcement rules. Let us explore the first of these rules—the Allow Rule.

Allow Rule

Allow Rules specifically allow ‘access’ to an ‘object’ by a ‘subject’. Here:

• access is defined by access permissions—such as read, write, execute, etc.
• object is defined by:
  • the security context called the target context (tcontext)
  • the class of the object called the target class (tclass). Examples of the target class can be file, dir, socket, etc.
• subject is defined by the security context called the source context (scontext)

A typical allow rule can be described as follows: Allow the Web Process (Apache server) to read the file (/var/www/html/index.html).

If the above rule is not present in the policy, the Apache process will not be able to read a file in its default ‘documentroot’ folder and will be denied access.

To implement the above allow rule, we need to evaluate Access Permissions Required, Target Context (tcontext), Target Class (tclass), and Source Context (scontext).

For our example, the results will be as follows:

• Access Permissions Required — read
• Target Context (tcontext) — security context of /var/www/html/index.html

  [root@vbg ~]# ls -Z /var/www/html/index.html
  system_u:object_r:httpd_sys_content_t:s0

• Target Class (tclass) — file Source Context (scontext): (security context of the httpd process)

  [root@vbg ~]# ps axZ | grep httpd
  user_u:system_r:httpd_t:s0

Taking the above into consideration, our allow rule changes from:

Allow the Web Process (Apache server) to read the file (/var/www/html/index.html)

…to:

Allow the Source Context user_u:system_r:httpd_t:s0 permission to read on the class file bearing a Target Context of system_u:object_r:httpd_sys_content_t:s0

To search for all allow rules, specify as follows:

[root@vbg ~]# sesearch --allow

To search for an allow rule that specifically contains scontext, tcontext and tclass, specify:

[root@vbg ~]# sesearch -s scontext -t tcontext -c tclass --allow

Since this rule exists in the default targeted policy, let us search for it using the sesearch command:

[root@vbg ~]# sesearch -s httpd_t -t httpd_sys_content_t -c file –allow
Found 2 av rules:
   allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock };
   allow httpd_t httpd_sys_content_t : file { ioctl read getattr lock };

Let us examine the syntax of the allow rule itself. The first word in a rule phrase specifies the type of the rule. Therefore, allow rules in a policy appear as — allow scontext tcontext:tclass permissions

By default, the rules in the targeted security policy do not allow the Web server to read a file of type tmp_t. You can test this by changing the type of the index.html file.

[root@vbg ~]# chcon -t tmp_t /var/www/html/index.html

Now try to open this Web page. You will receive a forbidden/access denied error. This is because of SELinux MAC rules. There is no ‘allow rule’ in the policy to allow this access.

If you want to allow the Apache server to be able to read this file, you will need to insert an allow rule to the policy. This rule will look like — allow httpd_t tmp_t: file {read }

To insert this rule into your policy, you will need to compile it and load it.

Modifying the base SELinux policy is not recommended, especially for beginners. Such rules can be compiled in separate policy modules and loaded into the memory. We will come to SELinux modules in a later part of this series.

Access Vector Cache

Just imagine a scenario where you have installed a new application and are unable to execute it. The SELinux default policy in your system prevents access to files and other resources. How do you find out which allow rules are required and which are not? Also, what kind of overhead will the checking of these rules create on system performance?

If you see the seinfo command output above, there are more than 80,000 allow rules in the default targeted policy. Checking for multiple subjects while simultaneously accessing multiple objects can create a serious performance bottleneck.

SELinux tackles the performance overhead issue in the traditional manner—by caching rules. An Access Vector Cache is created from rules being looked up into the policy, so that subsequent look-ups can occur from the AVC (Access Vector Cache). This provides significant performance benefits.

Access Vector Cache (AVC) denial logging gives an idea of why a particular access has been disallowed. Closer examination of these denial logs will enable you to figure out what allow rules need to be inserted into the policy to allow these actions.

Logging is a key feature of SELinux and it is important for security administrators to be able to decipher log messages. In the next series of this article we will explore how SELinux logging occurs and how to use the logs to effectively create allow rules.

Resolving SELinux errors

Once you have decoded the error from the log file, SELinux provides a plethora of tools to help solve the errors. Depending on the solutions and the security level desired by a systems administrator, the possible solutions can be applied to allow the action. The setroubleshoot RPM will be required for this.

The setroubleshoot RPM is an important tool in the SELinux systems administrator’s toolkit. If it is not installed in your system, please go ahead and install it.

sealert is one of the utilities provided. To understand this utility’s usage, issue the following command:

[root@vbg selinux]# sealert -h
        -b --browser        Launch the browser
        -h --help           Show this message
        -s --service        Start sealert as a dbus service
        -S --noservice      Start sealert without dbus service as stand alone app
        -l --lookupid id    Lookup alert by id
        -a --analyze file   Scan a log file, analyze it's AVC's
        -H --html_output    Ouput in html
        -v --verbose        Start in verbose mode

Let us first analyse the log file /var/log/audit/audit.log using sealert. To do so, enter the command that follows:

[root@vbg selinux]# sealert -a /var/log/audit/audit.log

Depending on the number of errors in the log file, an output containing the possible solutions to AVC denial errors in the log file will appear on the screen.

To analyse these solutions, you can redirect the output to a file:

[root@vbg selinux]# sealert -a /var/log/audit/audit.log > /tmp/my-selinux-error-solutions.txt

Each error and possible solution is mentioned in the text file (/tmp/my-selinux-error-solutions.txt) separated by a line of dashes. The AVC error example discussed in the above section has been analysed by sealert as:

Summary
    SELinux is preventing the /usr/sbin/httpd from using potentially mislabeled
    files (/var/www/html/index.html).

Detailed Description
    SELinux has denied /usr/sbin/httpd access to potentially mislabeled file(s)
    (/var/www/html/index.html).  This means that SELinux will not allow
    /usr/sbin/httpd to use these files.  It is common for users to edit files in
    their home directory or tmp directories and then move (mv) them to system
    directories.  The problem is that the files end up with the wrong file
    context which confined applications are not allowed to access.

Allowing Access
    If you want /usr/sbin/httpd to access this files, you need to relabel them
    using restorecon -v /var/www/html/index.html.  You might want to relabel the
    entire directory using restorecon -R -v /var/www/html.

Additional Information

Source Context                user_u:system_r:httpd_t:s0
Target Context                system_u:object_r:tmp_t:s0
Target Objects                /var/www/html/index.html [ file ]
Affected RPM Packages
Policy RPM
Selinux Enabled
Policy Type
MLS Enabled
Enforcing Mode
Plugin Name                   plugins.home_tmp_bad_labels
Host Name
Platform
Alert Count                   2
Line Numbers                  8796,8797,8798
                                                                                                           31755,0-1     70%

Raw Audit Messages

avc: denied { getattr } for comm="httpd" dev=hda3 egid=48 euid=48
exe="/usr/sbin/httpd" exit=0 fsgid=48 fsuid=48 gid=48 items=0 name="index.html"
path="/var/www/html/index.html" pid=3579 scontext=user_u:system_r:httpd_t:s0
sgid=48 subj=user_u:system_r:httpd_t:s0 suid=48 tclass=file
tcontext=system_u:object_r:tmp_t:s0 tty=(none) uid=48

The above output from sealert helps a systems administrator to:

1. Look at the raw log message
2. Understand why the AVC denial occurred (giving detailed description and summary)
3. View possible solutions to avoid the AVC denial (by allowing access)
4. View additional information

Executing the ‘Possible Solution’ would generally solve the AVC denial error.

If you execute the solution mentioned below:

[root@vbg selinux]# restorecon -v /var/www/html/index.html

…the security context of this file would change to system_u:object_r:httpd_sys_content_t:s0. This would remove the AVC denial and you would be able to browse your HTML page.

For those of us inclined to use the GUI, sealert can be initiated in the GUI mode, by giving the following command:

[root@vbg selinux]# sealert -b &

Please refer to Figure 2 below, which shows the output for the same error graphically in the browser.

Figure 2: sealert can also show errors in a graphical window

The setroubleshoot RPM also includes an init script called setroubleshoot. By enabling thesetroubleshoot script on startup using the chkconfig utility, setroubleshoot runs as a daemon in the background.

Every time an AVC denial occurs, a pop-up appears in the system tray (assuming you are working in the GUI mode). This helps systems administrators to troubleshoot SELinux errors on-the-fly.

At times, you might not be willing to choose the solution suggested by the sealert tool and would rather create your own allow rules in the SELinux policy. For example, I would want my Web server httpd to be able to read files of type tmp_t rather than restrict it to read only files of type httpd_sys_content_t.

In such situations, a new Allow Rule will have to be added to the Security Policy. This Allow Rule will permit a subject of httpd_t to read object files of type tmp_t.

The above would give you great flexibility in creating your own security environment and not just follow the standard policies that came with the system. At other times, you would require to create security policies for other applications that you may have installed on your system, for example, an Oracle database.

Do you need to build the entire SELinux policy for this?

That would appear to be an uphill task for most systems administrators. Therefore, SELinux allows sysadmins to create their own modules.

Instead of modifying the core policy, you can build modules of your own that can be loaded on top of the core policy. In these modules, you can declare your own types and rules.