What Is SELinux?
Securing servers with SELinux does away with dependency on DAC style access based on actual system users and roles. Instead, it introduces a three-string context system for each process or system user. The three strings, namely username, role, and domain, allow for more flexibility and control over system access. A process can only be allowed in a specific domain through policy configuration in SELinux. The only exception is when a process is launched into an explicitly defined context through the runcon command. However, if conflicting policies exist for such a process already in configuration, SELinux can deny such a transition into another context. That ensures that SELinux works on the principle of denying by default. Any process or user needs to have an explicit access configuration for a file or system resource before accessing it.
SELinux Operations and Commands
As an extension of common utility commands in the terminal, SELinux provides -Z switch, which allows for the display of the security context of the files and processes. Commands such as ps and ls benefit from this switch for quickly debugging or identifying errors in configuration. Below, a screenshot of the ls command is shown. The first part of each output line is the domain, the second is the type of object, and the third is the username in the SELinux configuration. This way, SELinux can provide full control over access to each file and process. The following commands are used to manipulate the context of files and directories. For example, if there is a need to change the context of all the files in the “/srv/web” directory to “httpd_sys_content_t”, the following command can be used: Since this context seen in the screenshot is already defined for the “/srv/web” directory recursively, SELinux displays a message to let the user know. If it is not defined, a successful semanage operation does not show any output. System administrators and users can enable, disable or make SELinux permissible through the use of the setenforce command. Similarly, to check what the enforcement status is at the moment, users can use the getenforce command as shown in the screenshot below.
What Is AppArmor?
AppArmor is supported in development by Canonical, the parent company that develops the Ubuntu distribution of Linux. AppArmor aims to be simpler and easier to use than SELinux and its profiles are created in the “/etc/apparmor.d/” directory. An AppArmor profile for the “/usr/bin/man” process is shown in the screenshot below.
AppArmor Operations and Commands
To see the status of Apparmor, the aa-status command is used. A sample output of the command is shown below. AppArmor profiles can be listed by the directory contents of “/etc/apparmor.d/”, as shown below. From the above list of profiles, if a user wants to disable the usr.bin.man profile, they can use the following command: Note that a disabled profile is located in the disable subdirectory of the main AppArmor profiles directory. To re-enable a profile that has been disabled, the following command is used:
Ease of Use Between SELinux and AppArmor
AppArmor works with file paths in the filesystem instead of working with strings for each file like SELinux does. One advantage of AppArmor is that the read, write, lock and other file operations are easier to set up than in SELinux. On the other hand, while SELinux provides more features for file access control, the features are implemented at a much lower level in the system. Therefore, users have to learn how to use mknod, network sockets, and other system operations to work with SELinux. For everyone who is not a system administrator, it is much easier to learn how to use AppArmor. AppArmor also provides a learning mode that is used for logging violations of access control. This mode does not restrict or prevent access in case of a violation, instead collecting data over time to enable the creation of a separate AppArmor profile based on the behavior of programs for each recorded access infraction. There is no similar mode available in SELinux. Image credits: AppArmor’s Wiki Page and SELinux’s Wiki Page. All screenshots by Zeeman Memon.