Home > Articles

  • Print
  • + Share This
This chapter is from the book

Context-Based Permissions

Files and directories may be compromised by users who either do not understand permissions or accidently provide more access than intended. This is a reflection of 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.

Note that traditional Linux permissions 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).

Context-based permissions can be configured to accommodate for this flaw by providing an additional level of security when processes (programs) are used to access files. This section covers two commonly used context-based methods: SELinux and AppArmor.

SELinux Configurations

An SELinux security policy can be applied that will 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 will still be 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 where you have many active processes that provide a variety of services. For example, one of these processes may be a web server, as shown in the following example:

root@OCS:~# 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

Note that in the preceding 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 only used 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 that 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@OCS:~# ls -l /etc/passwd
-rw-r--r-- 1 root root 2690 Dec 11  2018 /etc/passwd

As you can see from the output of the preceding command, all users have the ability to view the contents of the /etc/passwd file. Ask yourself this: Do you want some random person (usually called a 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 each can only access 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.

This subsection covers the essentials of managing an SELinux security policy.


When in disabled mode, SELinux is not functional at all. No checks are performed when users attempt to access files or directories. See the “setenforce” and “getenforce” subsections in this chapter for more details on viewing and changing the SELinux mode.


When in permissive mode, SELinux performs checks but will never block access to a file or directory. This mode is designed for troubleshooting problems as log messages are created when in this mode. See the “setenforce” and “getenforce” subsections in this chapter for more details on viewing and changing the SELinux mode.


When in enforcing mode, SELinux performs checks and will block access to files or directories if necessary. See the “setenforce” and “getenforce” subsections in this chapter for more details on viewing and changing the SELinux mode.

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 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.


See the “SELinux Policy” subsection in this chapter.

SELinux Tools

A large number of tools are used to manage SELinux. This subsection covers the tools you should know for the Linux+ exam.


You can disable the security policy (useful when testing a new policy or troubleshooting SELinux problems) with the setenforce command:

root@OCS:~# setenforce 0
root@OCS:~# getenforce

While in “Permissive” mode, SELinux will not block any access to files and directories, but warnings will be issued and viewable in the system log files.


Use the getenforce command to determine the current SELinux mode:

root@OCS:~# getenforce

The result “Enforcing” means SELinux is installed and the security policy is currently active. See the “disabled,” “permissive,” and “enforcing” subsections in this chapter for more details regarding SELinux modes.


The sestatus command provides overall status information about SELinux:

root@OCS:~# 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


To set an SELinux Boolean, use the setsebool command:

root@OCS:~# getsebool -a | grep abrt_anon_write
abrt_anon_write --> off
root@OCS:~# setsebool abrt_anon_write 1
root@OCS:~# getsebool -a | grep abrt_anon_write
abrt_anon_write --> on

See the “getsebool” subsection next for information about Boolean values.


Part of an SELinux security policy includes Booleans. A Boolean is a setting that can be assigned either a true or a false value. This value can affect the behavior of the SELinux policy.

root@OCS:~# getsebool -a | head
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
authlogin_nsswitch_use_ldap --> off
authlogin_radius --> off
authlogin_yubikey --> off
awstats_purge_apache_log_files --> off

In order to determine what a Boolean is used for, use the semanage command:

root@OCS:~# 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

See the “setsebool” subsection in this chapter for information on how to set a Boolean value.


Use the chcon command to change the context of a file or directory:

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

See the “ls -Z” subsection in this chapter for more details regarding security contexts.


There are 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.


root@OCS:~# 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.

See the “ls -Z” subsection in this chapter for more details regarding security contexts.

ls -Z

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

root@OCS:~# ps -fe | 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 (note that the SELinux context contains so much data that the filename cannot fit on the same line):

root@OCS:~# ls -Z /var/www/html/index.html

ps -Z

See the “ls -Z” subsection in this chapter.


AppArmor is a MAC system that plays a similar role to SELinux in that it provides a context-based permission model. This subsection describes the key components of AppArmor that are exam testable.


An AppArmor profile is a rule set that describes how AppArmor should restrict a process. A profile can be disabled for a specific profile by using the aa-disable command. Here’s an example:

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


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

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

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

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

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


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


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


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

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.