Chapter 7. Implementing Mandatory Access Control with SELinux and AppArmor

As we saw in the previous chapters, Discretionary Access Control allows users to control who can access their own files and directories. But, what if your company needs to have more administrative control over who accesses what? For this, we need some sort of Mandatory Access Control or MAC.

The best way I know to explain the difference between DAC and MAC is to hearken back to my Navy days.  I was riding submarines at the time, and I had to have a Top Secret clearance to do my job. With DAC, I had the physical ability to take one of my Top Secret books to the mess decks, and hand it to a cook who didn't have that level of clearance. With MAC, there were rules that prevented me from doing so. On operating systems, things work pretty much the same way. 

There are several different MAC systems that are available for Linux. The two that we'll cover in this chapter are SELinux and AppArmor.

In this chapter, we'll cover the...

How SELinux can benefit a systems administrator

SELinux is a free open source software project that was developed by the U.S. National Security Agency. While it can theoretically be installed on any Linux distro, the Red Hat-type distros are the only ones that come with it already set up and enabled. It uses code in Linux kernel modules, along with filesystem-extended attributes, to help ensure that only authorized users and processes can access either sensitive files or system resources. There are three ways in which SELinux can be used:

• It can help prevent intruders from exploiting a system
• It can be used to ensure that only users with the proper security clearance can access files that are labeled with a security classification
• In addition to MAC, SELinux can also be used as a type of role-based access control

In this chapter, I'll only be covering the first of these three uses because that is the most common way in which SELinux is used. There's also the fact that covering all three of these...

Setting security contexts for files and directories

Think of SELinux as a glorified labeling system. It adds labels, known as security contexts, to files and directories through extended file attributes. It also adds the same type of labels, known as domains, to system processes. To see these contexts and domains on your CentOS machines, use the -Z option with either ls or ps.  For example, files and directories in my own home directory would look as follows:

[donnie@localhost ~]$ ls -Z
drwxrwxr-x. donnie donnie unconfined_u:object_r:user_home_t:s0 acl_demo_dir
-rw-rw-r--. donnie donnie unconfined_u:object_r:user_home_t:s0 yum_list.txt
[donnie@localhost ~]$

Processes on my system would look something like this:

[donnie@localhost ~]$ ps -Z
LABEL                             PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1322 pts/0 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3978 pts/0 00:00:00 ps
[donnie@localhost ~]$

Now, let's break this...

Troubleshooting with setroubleshoot

So, you're now scratching your head and saying, "When I can't access something that I should be able to, how do I know that it's an SELinux problem?" Ah, I'm glad you asked.

Viewing setroubleshoot messages

Whenever something happens that violates an SELinux rule, it gets logged in the /var/log/audit/audit.log file. Tools are available that can let you directly read that log, but to diagnose SELinux problems, it's way better to use setroubleshoot. The beauty of setroubleshoot is that it takes the cryptic, hard-to-interpret SELinux messages from the audit.log file and translates them into plain, natural language. The messages that it sends to the /var/log/messages file even contain suggestions about how to fix the problem. To show how this works, let's go back to our problem where a file in the /var/www/html directory had been assigned the wrong SELinux type. Of course, we knew right away what the problem was because there was only one file in that directory...

Working with SELinux policies

So far, all we've looked at is what happens when we have an incorrect SELinux type set on a file and what to do to set the correct type. Another problem we may have would come about if we need to allow an action that is prohibited by the active SELinux policy.

Viewing the Booleans

Booleans are part of what makes up an SELinux policy, and each Boolean represents a binary choice. In SELinux policies, a Boolean either allows something or it prohibits something. To see all of the Booleans on your system, run the getsebool -a command. (It's a long list, so I'll only show partial output here.):

[donnie@localhost ~]$ getsebool -a
abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
antivirus_can_scan_system --> off
antivirus_use_jit --> off
auditadm_exec_content --> on
. . .
. . .
xserver_object_manager --> off
zabbix_can_network --> off
zarafa_setrlimit --> off
zebra_write_config --> off
zoneminder_anon_write...

How AppArmor can benefit a systems administrator

AppArmor is the Mandatory Access Control system that comes installed with the SUSE and the Ubuntu families of Linux. Although it's designed to do pretty much the same job as SELinux, its mode of operation is substantially different:

• SELinux labels all system processes and all objects such as files, directories, or network ports. For files and directories, SELinux stores the labels in their respective inodes as extended attributes. (An inode is the basic filesystem component that contains all information about a file, except for the file name.)
• AppArmor uses pathname enforcement, which means that you specify the path to the executable file that you want for AppArmor to control. This way, there's no need to insert labels into the extended attributes of files or directories.
• With SELinux, you have system-wide protection out of the box.
• With AppArmor, you have a profile for each individual application.
• With either SELinux or AppArmor, you might occasionally...

Looking at AppArmor profiles

In the /etc/apparmor.d directory, you'll see the AppArmor profiles for your system.  (The SELinux folk say policies, but the AppArmor folk say profiles.):

donnie@ubuntu3:/etc/apparmor.d$ ls -l
total 72
drwxr-xr-x 5 root root  4096 Oct 29 15:21 abstractions
drwxr-xr-x 2 root root  4096 Nov 15 09:34 cache
drwxr-xr-x 2 root root  4096 Oct 29 14:43 disable
drwxr-xr-x 2 root root  4096 Apr  5  2016 force-complain
drwxr-xr-x 2 root root  4096 Oct 29 15:21 local
drwxr-xr-x 2 root root  4096 Oct 29 15:02 lxc
-rw-r--r-- 1 root root   198 Jun 14 16:15 lxc-containers
-rw-r--r-- 1 root root  3310 Apr 12  2016 sbin.dhclient
drwxr-xr-x 5 root root  4096 Oct 29 15:21 tunables
-rw-r--r-- 1 root root   125 Jun 14 16:15 usr.bin.lxc-start
-rw-r--r-- 1 root root   281 May 23  2017 usr.lib.lxd.lxd-bridge-proxy
-rw-r--r-- 1 root root 17667 Oct 18 05:04 usr.lib.snapd.snap-confine.real
-rw-r--r-- 1 root root  1527 Jan  5  2016 usr.sbin.rsyslogd
-rw-r--r-- 1 root root  1469 Sep  8 15...

Working with AppArmor command-line utilities

Whether or not you have all the AppArmor utilities you need will depend on which Linux distro you have. On my OpenSUSE Leap workstation, the utilities were there out of the box.  On my Ubuntu Server virtual machine, I had to install them myself:

sudo apt install apparmor-utils

First, let's look at the status of AppArmor on the Ubuntu machine:

donnie@ubuntu5:~$ sudo aa-status
[sudo] password for donnie:

apparmor module is loaded.
13 profiles are loaded.
13 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/mysqld
   /usr/sbin/tcpdump
   lxc-container-default
   lxc-container-default-cgns
   lxc-container-default-with-mounting
   lxc-container-default-with-nesting
0 profiles are in complain...

Troubleshooting AppArmor problems

So, I've been here racking my brain for the past several days, trying to come up with a good troubleshooting scenario. It turns out that I didn't need to. The Ubuntu folk have handed me a good scenario on a silver platter, in the form of a buggy Samba profile.

As you've just seen, I used aa-enforce to put the two Samba-related profiles into enforce mode. But, watch what happens now when I try to restart Samba in order to get the profiles to take effect:

donnie@ubuntu3:/etc/apparmor.d$ sudo systemctl restart smbd
Job for smbd.service failed because the control process exited with error code. See "systemctl status smbd.service" and "journalctl -xe" for details.
donnie@ubuntu3:/etc/apparmor.d$

Okay, that's not good.  Looking at the status for the smbd service, I see this:

donnie@ubuntu3:/etc/apparmor.d$ sudo systemctl status smbd
● smbd.service - LSB: start Samba SMB/CIFS daemon (smbd)
   Loaded: loaded (/etc/init.d/smbd; bad; vendor preset: enabled)
   Active...

Summary

In this chapter, we looked at the basic principles of Mandatory Access Control and compared two different Mandatory Access Control systems. We saw what SELinux and AppArmor are and how they can help safeguard your systems from malicious actors. We then looked at the basics of how to use them and the basics of how to troubleshoot them. We also saw that even though they're both meant to do the same job, they work in vastly different ways.

Whether you're working with AppArmor or with SELinux, you'll always want to thoroughly test a new system in either complain or permissive mode before you put it into production.  Make sure that what you want to protect gets protected, while at the same time, what you want to allow gets allowed. After you place the machine into production, don't just assume that you can automatically change a policy setting every time you see a policy violation occur. It could be that nothing is wrong with your Mandatory Access Control setup and that MAC is just doing...