SELinux and AppArmor

By Ross Brunson and William "Bo" Rothwell

Date: Jan 10, 2020

Return to the article

This chapter covers the following topics:

• SELinux configurations

• SELinux contexts

• AppArmor

This chapter covers the following objective:

• Objective 3.1: Given a scenario, apply or acquire the appropriate user and/or group permissions and ownership.

In Chapter 9, “File Permissions and Escalation,” you learned how users can protect their own files and directories by using permissions. Permissions are a very useful feature; however, they do have one major weak point: the user.

Users are often confused about permissions. A typical user might not understand the complexity of Linux permissions, particularly nuances such as write permission on a directory meaning that users can delete all the files in that directory.

There needs to be a way to protect users from themselves. Several available technologies enable an administrator to add another layer of protection on top of regular file and directory permissions. This chapter explores two of these technologies: SELinux and AppArmor.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter or simply jump to the “Exam Preparation Tasks” section for review. If you are in doubt, read the entire chapter. Table 10-1 outlines the major headings in this chapter and the corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 10-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. What is mandatory access control designed to secure?

   1. User accounts

   2. Files and directories

   3. Group accounts

   4. Network ports

2. Which of the following is a valid SELinux mode? (Choose all that apply.)

   1. Disabled

   2. Enforcing

   3. Permissive

   4. None of these are correct.

3. Which command is used to display security context on processes?

   1. show

   2. list

   3. ps

   4. ls

4. Which command is used to display security context on files?

   1. show

   2. list

   3. ps

   4. ls

5. Which of the following is considered a MAC security system?

   1. SecureMAC

   2. AppArmor

   3. Lockdown

   4. AppSecure

Do I Know This Already?

1. B

2. A, B, and C

3. C

4. D

5. B

Foundation Topics

Files and directories may be compromised by users who either do not understand permissions or who are accidently provided with more access than intended. There’s an old system administration saying: “If we didn’t have users, nothing would break, and the system would be more secure.” Of course, the response to this saying is, “Without users, we wouldn’t have a job!” Users’ mistakes often do provide unintended access to the data that is stored in files.

Context-based access can be configured to deal with compromised permissions by providing an additional level of security when processes are used to access files. The control of file and directory access is not in the hands of the user but rather is handled by the administer.

It isn’t just user files and directories that are a concern. Imagine a situation in which a remote hacker is able to utilize an exploit to gain control of your web server process (the httpd process). Without context-based controls, this hacker could direct the httpd process to read critical system files (such as the /etc/passwd file) and get information that could lead to further intrusions on the system or the network.

Traditional Linux permissions (read, write, and execute on files and directories) make use of discretionary access control (DAC), while context-based permissions utilize mandatory access control (MAC). However, when a context-based solution is enabled, DAC still applies (both MAC and DAC are enforced). Typically, the MAC controls are first evaluated and, if the access is granted, then the file’s permissions are checked.

This chapter covers two commonly used context-based methods: SELinux and AppArmor.

SELinux Configurations

An SELinux security policy can require processes to be a part of an SELinux security context (think “security group”) in order to be able to access files and directories. Regular permissions are still used to further define access, but for accessing the file/directory, this SELinux policy would be applied first.

A bigger concern, and one that most SELinux policies are designed to address, is how daemon (or system) processes present a security risk. Consider a situation in which you have many active processes that provide a variety of services. For example, one of these processes might be a web server, as shown in the following example:

root@localhost:~# ps -fe | grep httpd
root      1109      1  0  2018 ?        00:51:56 /usr/sbin/httpd
apache    1412  1109  0  Dec24 ?        00:00:09 /usr/sbin/httpd
apache    4085  1109  0  05:40 ?        00:00:12 /usr/sbin/httpd
apache    8868  1109  0  08:41 ?        00:00:06 /usr/sbin/httpd
apache    9263  1109  0  08:57 ?        00:00:04 /usr/sbin/httpd
apache   12388  1109  0  Dec26 ?        00:00:47 /usr/sbin/httpd
apache   18707  1109  0  14:41 ?        00:00:00 /usr/sbin/httpd
apache   18708  1109  0  14:41 ?        00:00:00 /usr/sbin/httpd
apache   19769  1109  0  Dec27 ?        00:00:15 /usr/sbin/httpd
apache   29802  1109  0  01:43 ?        00:00:17 /usr/sbin/httpd
apache   29811  1109  0  01:43 ?        00:00:11 /usr/sbin/httpd
apache   29898  1109  0  01:44 ?        00:00:10 /usr/sbin/httpd

In this output, each line describes one Apache web server process (/usr/sbin/httpd) that is running on the system. The first part of the line is the user who initiated the process. The process that runs as root is used only to spawn additional /usr/sbin/ httpd processes. The others, however, respond to incoming web page requests from client utilities (web browsers).

Imagine for a moment that a security flaw is discovered in the software for the Apache web server; this flaw allows a client utility to gain control of one of the /usr/sbin/httpd processes and issue custom commands or operations to that process. One of those operations could be to view the content of the /etc/passwd file, which would be successful because of the permissions placed on this file:

root@localhost:~# ls -l /etc/passwd
-rw-r--r-- 1 root root 2690 Dec 11  2018 /etc/passwd

As you can see from the output of this command, all users have the ability to view the contents of the /etc/passwd file, based on the fact that all users have read permission. Do you want some random hacker to have the ability to view the contents of the file that stores user account data?

With an SELinux policy, the /usr/sbin/httpd processes can be “locked down” so that each one can access only a certain set of files. This is what most administrators use SELinux for: to secure processes that may be compromised by hackers making use of known (or, perhaps, unknown) exploits.

SELinux Mode

There are three SELinux modes:

• Disabled: When in disabled mode, SELinux is not functional at all. No checks are performed when users attempt to access files or directories.

• Enforcing: When in enforcing mode, SELinux performs checks and blocks access to files or directories, if necessary.

• Permissive: When in permissive mode, SELinux performs checks but never blocks access to a file or directory. This mode is designed for troubleshooting problems as log messages are created when in this mode.

Use the getenforce command to determine the current SELinux mode:

root@localhost:~# getenforce
Enforcing

The result Enforcing means SELinux is installed, and the security policy is currently active.

You can change the mode (which is useful when testing a new policy or trouble-shooting SELinux problems) by issuing the setenforce command:

root@localhost:~# setenforce 0
root@localhost:~# getenforce
Permissive

While in permissive mode, SELinux does not block access to files and directories, but warnings are issued and viewable in the system log files.

You can switch between enforcing and permissive modes, but disabling SELinux requires changing a configuration file and then rebooting the system. For example, on a RHEL (Red Hat Enterprise Linux) system, you would change the SELINUX setting in the /etc/selinux/config file as follows:

root@localhost:~# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Conversely, if the current SELinux mode is disabled, you can change the SELINUX setting to either enforcing or permissive in the /etc/selinux/config file and reboot the system. It is always a good policy to verify that a change has taken place by running the getenforce command after the reboot is complete.

SELinux Policy

An SELinux policy is a collection of rules that determine what restrictions are imposed by the policy. The policy itself is often very complex, and details are beyond the scope of the Linux+ exam. It is, however, important to know that the policy sets the restrictions based on rules.

You should also know that one of the most commonly used policies is the targeted policy. This policy normally exists by default on systems that have SELinux installed, and it is typically the default policy that is enabled when SELinux is first enabled.

A targeted policy contains rules that are designed to protect the system from services rather than regular users. Each service is assigned one or more security contexts, Boolean values, and additional rules that limit the service’s ability to access files and directories.

The sestatus command provides overall status information about SELinux, including the current policy:

root@localhost:~# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

SELinux Booleans

What exactly a policy consists of and how to create a policy are beyond the scope of the Linux+ exam and, as a result, this book. However, you can modify the behavior of a policy by using Booleans. A Boolean is a true/false value that changes how SELinux performed MAC.

An SELinux policy typically has dozens of different Booleans. To determine what a Boolean is used for, use the semanage command:

root@localhost:~# semanage boolean -l | head
SELinux boolean             State  Default Description
privoxy_connect_any     (on   ,   on)  Allow privoxy to connect any
smartmon_3ware          (off  ,  off)  Allow smartmon to 3ware
mpd_enable_homedirs     (off  ,  off)  Allow mpd to enable homedirs
xdm_sysadm_login        (off  ,  off)  Allow xdm to sysadm login
xen_use_nfs             (off  ,  off)  Allow xen to use nfs
mozilla_read_content    (off  ,  off)  Allow mozilla to read content
ssh_chroot_rw_homedirs  (off  ,  off)  Allow ssh to chroot rw homedirs
mount_anyfile           (on   ,   on)  Allow mount to anyfile

For example, in this output, there is a Boolean named xdm_sysadm_login. XDM is a display manager, which means it is a tool that enables a user to log in to the system by using a GUI interface. This Boolean is used to determine whether the XDM software will allow the root user to log in. (off, off) is used to display the default value and the current value for this Boolean. In this case, off means the root user is not able to log in using the GUI interface because the description for this Boolean is “Allow xdm to sysadm login.”

You can also use the getsebool command to display just the current value of a Boolean:

root@localhost:~# getsebool -a | head
xdm_sysadm_login --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
antivirus_can_scan_system --> off
antivirus_use_jit --> off
auditadm_exec_content --> on
authlogin_nsswitch_use_ldap --> off
authlogin_radius --> off
authlogin_yubikey --> off
awstats_purge_apache_log_files --> off

When a Boolean is provided as an argument, the getsebool command gives only that Boolean’s current value:

root@localhost:~# getsebool xdm_sysadm_login
xdm_sysadm_login --> off

To set an SELinux Boolean as either on or off, use the setsebool command:

root@localhost:~# getsebool xdm_sysadm_login
xdm_sysadm_login --> off
root@localhost:~# setsebool xdm_sysadm_login 1
root@localhost:~# getsebool xdm_sysadm_login
xdm_sysadm_login --> on

Provide the argument 0 to turn off a Boolean and 1 to turn on a Boolean.

Note that, by default, the setsebool command modifies only the current state of a Boolean. A reboot causes all Booleans to return to their previous status unless the -P (for persistent) option is used with the setsebool command:

root@localhost:~# setsebool -P xdm_sysadm_login 1

The Boolean values are typically a bit lengthy and a pain to type. Commands like setsebool and getsebool provide a unique tab completion feature. For example, note the behavior of the following when the Tab character is pressed:

root@localhost:~# setsebool samba_<tab>
samba_create_home_dirs             samba_portmapper
samba_domain_controller            samba_run_unconfined
samba_enable_home_dirs             samba_share_fusefs
samba_export_all_ro                samba_share_nfs
samba_export_all_rw

SELinux Contexts

Just how does SELinux protect files (and directories) from unauthorized use? The answer is by using SELinux contexts.

Each file can have a context applied that will affect the ability of a process to access the file. Processes themselves have an SELinux context applied, and this context essentially places the processes in a security group.

Each process runs with a security context. To see this, use the -Z option to the ps command as shown here (where the head command is used simply to limit the output of the command):

root@localhost:~# ps -eZ | grep httpd | head -2
system_u:system_r:httpd_t:s0 root      1109     1  0  2018 ?
  00:51:56 /usr/sbin/httpd
system_u:system_r:httpd_t:s0 apache    1412  1109  0 Dec24 ?
  00:00:09 /usr/sbin/httpd

The security context (system_u:system_r:httpd_t:s0) is complicated, but for understanding the basics of SELinux, the important part is httpd_t, which is like a security group or domain. As part of this security domain, the /usr/sbin/httpd process can only access files that are allowed by the security policy for httpd_t. This policy is typically written by someone who is an SELinux expert, and that expert should have proven experience regarding which processes should be able to access specific files and directories on the system.

Files and directories also have an SELinux security context that is defined by the policy. To see a security context for a specific file, use the -Z option to the ls command:

root@localhost:~# ls -Z /var/www/html/index.html
unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

Note here that the SELinux context contains so much data that the filename cannot fit on the same line. As you might be able to conclude, a process running with the security context system_u:system_r:httpd_t:s0 is able to access files that have been labeled with the u:object_r:httpd_sys_content_t:s0 context. It isn’t always so simple as SELinux Booleans can have a major impact on how contexts are applied, but this is essentially the idea. Remember that you don’t need to be an SELinux expert for the Linux+ exam (which is a good thing because it is a very large topic).

How did the context of u:object_r:httpd_sys_content_t:s0 get applied to the /var/www/html/index.html file? Typically, SELinux security contexts are applied automatically, depending on where the file is placed. So, a new file placed in the /var/www/html directory would also be labeled with the context u:object_r:httpd_sys_content_t:s0.

In some cases, you might need to apply this context manually. For example, if you were to move a file from another location, it might retain its original security context. In such cases, use the chcon command to change the context of a file or directory:

root@localhost:~# chcon -t user_home_t /var/www/html/index.html

You can also take advantage of the SELinux rules that define the default security contexts for a majority of the system files. The restorecon command is used to reset the default security context on a file or directory based on its current location and these SELinux rules. Here is an example:

root@localhost:~# restorecon /var/www/html/index.html

A commonly used option to the restorecon command is the -R option, which performs the changes recursively on a directory structure.

AppArmor

AppArmor is a MAC system that plays a role similar to SELinux in that it provides a context-based permission model. This section describes the key components of AppArmor that might be tested on the Linux+ exam.

aa-disable

An AppArmor profile is a rule set that describes how AppArmor should restrict a process. It is possible to disable a profile for a specific profile by using the aa-disable command. Another technique that is commonly used is showed in the following example:

root@localhost:~# ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/
  apparmor.d/disable
root@localhost:~#  apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld

root@localhost:~# rm /etc/apparmor.d/disable/usr.sbin.mysqld
root@localhost:~#  apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld

aa-complain

If you need to troubleshoot an AppArmor profile, it is best to put it into complain mode. In this mode, no restrictions are enforced, but any problems will be reported.

Use the aa-complain command to put a profile into complain mode:

root@localhost:~#  aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

To put the profile back into enforcing mode, use the following command:

root@localhost:~#  sudo aa-enforce /usr/sbin/mysqld
Setting /usr/sbin/mysqld to enforce mode

aa-unconfined

Use the aa-unconfined command to list processes that are not restricted by the AppArmor profiles.

/etc/apparmor.d/

The /etc/apparmor.d directory is the location of the definitions of the AppArmor profiles. Knowing how to create or read these files is beyond the scope of the Linux+ exam, but it is important to know the locations of these profiles in order to determine which profiles are available and to use the AppArmor commands, such as the aa-disable command.

/etc/apparmor.d/tunables

The /etc/apparmor.d/tunables directory holds files that can be used to fine-tune the behavior of AppArmor. Knowing how to create or read these files is beyond the scope of the Linux+ exam.

Summary

In this chapter you learned the essentials of mandatory access control (MAC) and how this feature works with discretionary access control (DAC) to provide a more secure filesystem. You also learned about two of the main MAC solutions for Linux: SELinux and AppArmor.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 30, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 10-2 lists these key topics and the page number on which each is found.

Table 10-2 Key Topics for Chapter 10

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

• SELinux

• AppArmor

• mandatory access control (MAC)

• discretionary access control (DAC)

• SELinux policy

• SELinux context

• SELinux Boolean

Review Questions

The answers to these review questions are in Appendix A.

1. __________ is the use of Linux file and directory permissions to limit access to these items.

2. __________ makes use of security groups or domains to limit access to objects, such as files and directories.

3. Which of the following are SELinux contexts applied to? (Choose all that apply.)

   1. Files

   2. Users

   3. Processes

   All of these answers are correct.

4. In which mode is SELinux not functional at all?

   1. Permissive

   2. Disabled

   3. Inactive

   4. Null

5. Which command displays the current SELinux mode?

6. What command provides overall status information about SELinux?

7. Which of the following is an SELinux value that is used to change the behavior of an SELinux security policy?

   1. Flag

   2. Context

   3. Switch

   4. Boolean

8. Which option to the ps and ls commands displays SELinux security contexts?

9. AppArmor can be put into complain mode by using the __________ command.

10. The __________ command displays a list of processes not restricted by AppArmor profiles.

Answer

1. DAC

2. MAC

3. A and C. Answer B is incorrect because SELinux contexts are not applied to user accounts. Answer D is incorrect because answer B is incorrect.

4. B. Answer A is incorrect because SELinux does function in permissive mode (but doesn’t block access). Answers C and D are incorrect because these are not valid SELinux modes.

5. getenforce

6. sestatus

7. D. Answers A and C are incorrect because these are not valid SELinux terms. Answer B is incorrect because this is a feature that is applied to a file or directory, not a feature that changes a security policy.

8. -Z

9. aa-complain

10. aa-unconfined

© 2024 Pearson Education, Pearson IT Certification. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240