- File and Directory Permissions
- Context-Based Permissions
- Privilege Escalation
- User Types
This chapter is from the book
This chapter is from the book
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.
disabled
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.
permissive
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.
enforcing
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.
targeted
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.
setenforce
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 Permissive
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.
getenforce
Use the getenforce command to determine the current SELinux mode:
root@OCS:~# getenforce Enforcing
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.
sestatus
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
setsebool
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.
getsebool
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.
chcon
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.
restorecon
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.
Example:
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 unconfined_u:object_r:httpd_sys_content_t:s0/var/www/html/index.html
ps -Z
See the “ls -Z” subsection in this chapter.
AppArmor
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.
aa-disable
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 /etc/apparmor.d/disable 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 /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, 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
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. 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.
/etc/apparmor.d/tunables
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.