Available in ELinOS 7.0.2 or higher: www.sysgo.com/elinos

SELinux is one of the Linux Security Modules, used to enforce mandatory access control (MAC) over all processes. Like other LSM’s, it hooks into various Linux kernel calls and allows/disallows them according to the loaded policy rules. This is independent on the common Discretionary Access Control (DAC) system, thus even the root user must pass the SELinux permissions and doesn’t have unlimited control by default.

Note that while Android uses SELinux as well, the tooling, formats and especially rules differ.

The base operation principle is labeling all controlled system resources, such as files, sockets, users, processes etc. Afterwards, the loaded rules determine which resource types can access other resource types, type transitions when a file is executed etc.

Since setting up the rules for a new system is often a non-trivial task, especially for the initial bring-up it is helpful to not have all the rules in operation. This could mean for example locking yourself out from the system, because it would disallow login. For this, SELinux is able to operate in a permissive mode, which still uses all the rules specified by the current policy – but instead of denying the access, an audit log message is produced. The audit message usually contains the source and target contexts and the operation to be performed – which would fail in the enforcing mode of SELinux. This information can be used to find which rule is missing in the policy, or perhaps wrong labeling of some files. The permissive and enforcing modes can be also switched in runtime, however allowing this is not a good idea from the security standpoint.

SELinux Base Configuration

The base configuration file directory for selinux is /etc/selinux. Here, the file /etc/selinux/config determines, which policy is loaded (SELINUXTYPE) and whether the default mode is enforcing or permissive (SELINUX). The default mode may be overridden by kernel boot parameters as well.

After the SELinux-enabled init process (such as the BusyBox init in ELinOS provides) starts, one of the first steps it does it loading the policy from /etc/selinux/$SELINUXTYPE/policy/ directory. Note that there are several versions of SELinux policy files, differing in the various features they support – such as IPv6 support. The maximum policy version that the kernel supports can be determined e.g. using sestatus command, which also shows other current settings of SELinux:

All recent kernels should support at least policy version 30.

Policy Types

In principle, the policy is always loaded from a single binary file – such as /etc/selinux/default/policy/policy.31. The format of the file is generated by  SELinux Common Intermediate Language (CIL) compiler (secilc). While it is possible to write the lisp-like CIL files manually, as shown e.g. with this OpenWRT policy, it is not too commonly used. The most commonly used refpolicy and Android approach is to use m4-macro-based higher level approach, which is then translated into the low-level language.

Implementation language aside, there are two approaches possible:

• Monolithic policy: The whole policy is maintained as one piece, though it may be split in multiple source files. One example of such policy is the dummy policy generated by the kernel tool mdp. The policy uses a single resource type and single role, allowing all access to all processes. Technically, all policies eventually become monolithic, before being loaded into the kernel.
• Module-based policy: To be able to dynamically extend the policy (depending e.g. on user or system requirements), these policies usually consist of a static base part and several modules, which can be dynamically loaded/unloaded. Technically, the userspace tools (such as semanage/semodule) combine the base and chosen modules and transform them into the monolithic policy to be loaded into kernel. Typically, the management tools keep intermediate files in /var/lib/selinux or similar.

Even the monolitic policies may be somewhat flexible thanks to booleans support by the kernel. This way, simple on/off switches (for example user_ping, alias ‘allow users use the ping command’, in the reference policy) can be adjusted in the policy without having to rebuild/reload the original policy.

Policy Tools

Filesystem Labelling

Once the proper policy is installed and prepared for use in kernel, it’s time to configure the rest of the system. Since the base of the SELinux operation are the labels, very probably the policy will require that the filesystem objects will be labelled properly. For example with refpolicy, the /sbin directory should labelled like this:

The labels themselves are part of the policy and reside usually alongside the binary policy file, for example  /etc/selinux/default/contexts/files/file_contexts. There are further configurations in the same directory, such as file_contexts.subs_dirs – where usually it is specified that sub-paths in /lib and /usr/lib are equivalent with respect to labelling.

The go-to tool to handle the labeling is restorecon. Running for example ‘restorecon -R /‘ will apply the labels on the whole root filesystem according to current policy. Similarly, if new content is created or moved and the labels don’t match, this command can be used to fix it.

When the system is booted for the first time, the filesystem may be not labelled. Even after restoring the labels, there may be already various processes started (even init) with incorrect labels – usually the simplest solution is to reboot the system into now-correctly labelled filesystem. This of course requires that the filesystem changes are persistent, which rules out RAM-based or read-only filesystems usage.

The policy cannot describe all possible custom system modifications. For example mkswap tool, when used with reference policy, cannot just access any file. One of the solutions is labelling the file in question manually: chcon -t swapfile_t /swp.

SELinux Runtime Status

Especially during development of the system, it is usually needed to adjust the SELinux rules to match the system organization. The tool pair getenforce/setenforce can switch the current enforcement flag of SELinux. The setenforce tool requires the linux kernel option CONFIG_SECURITY_SELINUX_DEVELOP to be active.

Sample Configuration/Operation with the Reference Policy

Setting up basic SELinux operation in ELinOS is easily done using the features:

This is enough to boot into a system with SELinux rules being applied:

However, depending on he system complexity, this may be only the beginning. In the more complex cases, complete rebuild of the (reference) policy may be required – again, this is out of scope of this document. Some operations and adjustments can however be also performed even on a running target system. Also those can be automatized so that they are performed only once at initial boot, at the same time as initial relabelling of the filesystem.

The already mentioned setsebool tool may be used to modify boolean flags of the policy currently in effect, such as ” user_ping” allowing regular users to use the ping command.

Finally, the seinfo tool can be used to dump various information about the current policy:

SELinux Module Management

The swiss-army-knife for manipulating modular policies is the semanage and semodule tool pair. The latter is actually a convenience wrapper for “semanage module” and is primarily used to load or unload modules.

Using semanage to manage SELinux Users

By default, the users map to SELinux user unconfined_u with relatively broad permissions:

To narrow them down, new users can be added. The reference policy contains the user “user_u”, which can be easily mapped to a linux user (here "setest"):

After logging in, use e.g. the id command to show the current SELinux user:

Right away, the consequences of this action are visible for example in the process list, where only handful of processes are visible:

Further can be added, such as guest users. Consult for example the extensive redhat manual pages.

semodule and audit2allow Utilities

The common case when a new module may be needed is when a command fails due to missing rules. Let’s create a simple example consisting of web page. As root, we’ll create /var/www/index.html as follows:

After login as setest user, printing the file will fail in the enforcing mode even if the permissions allow “other” users to read the file:

The immediate cause of the issue can be seen in the audit log:

To allow this operation, the tool audit2allow can be used to generate a module that can be loaded afterwards:

However, this still doesn’t solve the issue, further similar audit errors would be generated . This would mean multiple iterations of the above audit2allow and semodule operations. Another useful command here is “semodule -DB“, which disables the “dontaudit” rules. These may silently deny some access in the enforcing mode, but without audit logs messages.

The shortcut path to generate the module to allow the access is to switch to permissive mode. This way, the denials are still logged, but not enforced – and the problem can be solved in one step:

Afterwards, the file can be finally read by the setest user:

The module file (.te) generated above may be manually modified and rebuilt into .pp file using the combination of checkmodule (.te→.mod) and semodule_package (.mod→.pp) tools, as shown for example here.

More information at www.sysgo.com/elinos

Further Reading

• SELinux Notebook free ebook, describing in detail the SELinux internal and user-level operation: https://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf
• Red Had SElinux User’s and Administrator’ss Guide: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index including the troubleshooting section: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-troubleshooting-fixing_problems
• SELinux administrator’s cheat-sheet: https://opensource.com/article/18/7/sysadmin-guide-selinux
• Process lifecycle/domain transitions: https://wiki.gentoo.org/wiki/SELinux/Tutorials/How_does_a_process_get_into_a_certain_context