Understanding SELinux Basics

You can switch the SELinux mode temporarily or permanently.

# getenforce

# setenforce MODE_ID

SELINUX=permissive

The security context is a set of information assigned to a file or a process. It consists of SELinux user, role, type, level and category. This information is used to make access control decisions.

A SELinux context looks like this:

user_u:role_r:type_t:level:category

Tip: Focus on the SELinux type

For beginners working with SELinux, it is recommended to focus first on the SELinux type, which is type_t. This is because SELinux rules mainly use the SELinux type to define allowed access, a core concept known as Type Enforcement.

An understanding of SELinux types is critical, as they are frequently modified during SELinux administration.

To check the current security context of a file, you can list the file with ls -Z. The following example lists the security context of the file /etc/shadow:

#  ls -Z /etc/shadow
system_u:object_r:shadow_t:s0 /etc/shadow

To check the current security context of a process, you can display the current process state with ps -Z. The following example lists the security context of the systemd process:

#  ps -eZ | grep systemd
system_u:system_r:init_t:s0           1 ?        00:00:01 systemd
...

Tip: The -Z flag convention

Many command-line tools, such as ls, ps, mkdir, id, cp, and many more, implement their explicit SELinux handling by adding a -Z flag or option. To check for explicit SELinux handling, refer to the man page of the tool and look out for -Z.

SELinux rules define whether a subject's security context (source) is permitted or denied access to an object's security context (target), explicitly specifying the allowed or denied permissions and the class of the object being accessed.

SELinux rules generally follow this format:

rule_name source target:class permissions;

Tip: Listing SELinux rules

The setools-console package contains sesearch, which is a convenient tool to list all rules.

For example, to check if the loaded policy has a rule that allows passwd (process running with passwd_t type) write access to the /etc/shadow file (labeled as shadow_t), run:

#  sesearch -A -s passwd_t -t shadow_t -p write
allow passwd_t shadow_t:file { append create getattr ioctl link lock map open read relabelfrom relabelto rename setattr unlink watch watch_reads write };

This output shows that there is a rule, so the access is allowed.

In the SELinux ecosystem, various policy types, such as the widely used targeted policy, are designed with distinct security concepts and enforcement methodologies to address diverse requirements.

SUSE Linux Micro 6.2 is shipped with the targeted SELinux policy by default.

The design of this policy prioritizes the confinement of long-running and network-facing services, particularly on general-purpose server systems.

While the default targeted policy is designed to cover the most common use cases in default configuration, specialized workloads often need policy adjustments. For instance, scenarios involving custom network ports or unique file system layouts will require administrators to refine the existing policy.

Additionally, SELinux Booleans encapsulate specific policy modifications that, while potentially reducing the baseline security of a general-purpose system, are necessary for certain common workloads. This design allows administrators to selectively enable these adjustments only when required, maintaining a more secure default posture.

To facilitate such modifications, SELinux offers various tools. System administrators and software developers can customize the default policy to their specific requirements.

The audit.log file contains structured records. The ausearch utility is designed to query these logs effectively. The most common use is to search for recent AVC denials.

# ausearch -m AVC -ts recent
type=AVC msg=audit(1753703741.779:1779): avc:  denied  { getattr } for  pid=22212 comm="httpd-prefork" path="/srv/wwwcustom/vhosts/example.com/index.html" dev="vda3" ino=278 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=file permissive=0

Here, -m AVC filters for SELinux denials, and -ts recent limits the search to events that happened in the last 10 minutes. You can also use values like today, a specific date or boot.

The log entry contains all the information needed to understand the denial. The key fields are:

The example log states the process named httpd-prefork (running with the httpd_t context) was denied permission to getattr a file that has the var_t context.

This example AVC occurred when a Web server was configured to use a different directory (/srv/wwwcustom) for the served files instead of the default path. This needs to be adjusted in SUSE Enterprise Storage as well, which can be seen in Section 7.2, “Managing custom file contexts”.

Instead of requiring the development and compilation of custom policy rules, booleans encapsulate predefined policy adjustments. Their primary purpose is to accommodate common operational workloads that, if permitted by default in the main policy, could potentially reduce the baseline security posture of a general-purpose system.

Instead of requiring the development and compilation of custom policy rules, booleans encapsulate predefined policy adjustments. This allows selectively enabling or disabling specific functionalities on an as-needed basis.

These changes can be applied at runtime and take effect immediately. Administrators can configure Booleans to be effective temporarily for the current session or persistently across reboots.

# getsebool -a

abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
...

# semanage boolean -l

SELinux boolean               State   Default     Description

abrt_anon_write               (off  ,  off)       Allow abrt to anon write
abrt_handle_event             (off  ,  off)       Allow abrt to handle event
abrt_upload_watch_anon_write  (on   ,   on)       Allow abrt to upload watch anon write

# getsebool BOOLEAN_NAME

# semanage boolean -l | grep BOOLEAN_NAME

# sedispol /etc/selinux/targeted/policy/policy.34

# setsebool BOOLEAN_NAME BOOLEAN_VALUE

# setsebool -P BOOLEAN_NAME BOOLEAN_VALUE

# semanage boolean -m --BOOLEAN_VALUE  BOOLEAN_NAME

When changing the default location of configuration files or other files of a confined service, you likely need to define or modify the security contexts. These contexts, also called labels, are attached to certain files by SELinux.

For instance, if a Web server is configured to serve Web pages from a custom directory other than its default location, the corresponding SELinux file contexts need to be updated as well to permit this operation.

To update the security context of the files in a custom location permanently, you can use the semanage fcontext command. This command writes the new file context to the policy. Additionally, the restorecon command needs to be run afterward to reflect the policy change in the file system.

The challenge when updating the SELinux context for a workload is determining which SELinux context is needed during the customization. You can list all mappings of security contexts to files in the file system using:

# semanage fcontext -l

This will show a long list of regular expressions, to which file type they match and which security context the files will be assigned. This can be searched to find the appropriate labels.

# semanage fcontext -l | less
SELinux fcontext                                   type               Context

/                                                  directory          system_u:object_r:root_t:s0
/.*                                                all files          system_u:object_r:default_t:s0
/[^/]+                                             regular file       system_u:object_r:etc_runtime_t:s0
/\.autofsck                                        regular file       system_u:object_r:etc_runtime_t:s0
/\.autorelabel                                     regular file       system_u:object_r:etc_runtime_t:s0
/\.journal                                         all files          X:>>None>>
/\.suspended                                       regular file       system_u:object_r:etc_runtime_t:s0
/a?quota\.(user|group)                             regular file       system_u:object_r:quota_db_t:s0
/afs                                               directory          system_u:object_r:mnt_t:s0
/bin                                               directory          system_u:object_r:bin_t:s0
/bin/.*                                            all files          system_u:object_r:bin_t:s0

Another way is to consult the SELinux man page of the service that has the custom path and check which type needs to be set. The man page convention is SERVICE_selinux. For example, the SELinux man page for Web servers is named httpd_selinux.

When the correct type for the custom path has been identified, you can set it by using semanage fcontext and using the TYPE and a regular expression REGEX to match the custom file path:

 # semanage fcontext -a -t TYPE REGEX

For example, to set all files below /srv/wwwcustom to have the type httpd_sys_content_t:

 # semanage fcontext -a -t httpd_sys_content_t "/srv/wwwcustom(/.*)?"

You can verify if your modification is set up correctly by using the matchpathcon command:

# matchpathcon /srv/wwwcustom
/srv/wwwcustom	system_u:object_r:httpd_sys_content_t:s0

Then reflect the security context in the file system for that directory by resetting the security context:

# restorecon -Rv /srv/wwwcustom

Tip: Set equivalencies between the label of the default and custom location

When you are using a different location in the file system than the default one, you can check which security context would have been assigned to the default location and assign the same to the new location. For example, the default served location of a Web server is /srv/www. You want to move it to /srv/wwwcustom. Check out the label of the default location:

# matchpathcon /srv/www
/srv/www	system_u:object_r:httpd_sys_content_t:s0

Check out the label of the new custom location:

# matchpathcon /srv/wwwcustom
/srv/wwwcustom	system_u:object_r:var_t:s0

Set an equivalency between /srv/www and /srv/wwwcustom by running:

# semanage fcontext -a -e /srv/www /srv/wwwcustom

The new custom location now has the same label as the default one:

# matchpathcon /srv/wwwcustom
/srv/wwwcustom	system_u:object_r:httpd_sys_content_t:s0

Then, reset the security contexts in the file system:

# restorecon -Rv /srv/wwwcustom

Your workload should work now as expected.

In case you would like to remove the customization again, run:

 # semanage fcontext -d "/srv/wwwcustom(/.*)?"

By default, an SELinux-confined service can only bind to network ports that are defined in the policy with the correct port type. If you configure a service to listen on a non-standard port, SELinux will prevent it from starting.

For example, if you configure the SSH daemon to listen on port 2222, SELinux blocks it because only ports with the ssh_port_t type are accessible to the SSH service. To allow this, you must add the new port number to the SELinux policy.

To add a custom port definition permanently, you can use the semanage port command. This command writes the new port definition directly into the active SELinux policy. Unlike file contexts, you do not need to run a separate command like the restorecon command; the changes take effect immediately. However, you may need to restart the affected service.

To identify the correct port type for your service, list all existing port definitions:

# semanage port -l

This shows a list of port types, protocols and the port numbers or ranges assigned to them. You can search this list or consult the service's SELinux man page. For example, use the man sshd_selinux command to find the appropriate port type.

# semanage port -l | less
SELinux Port                          Proto    Port Number

...
ssh_port_t                     tcp      22
...

Once you have identified the correct port type, you can add your custom port using semanage port with the port type TYPE, protocol PROTO, and port number PORT:

# semanage port -a -t TYPE -p PROTO PORT

For example, to allow the SSH daemon to bind to the custom TCP port 2222, use:

# semanage port -a -t ssh_port_t -p tcp 2222

You can then verify your modification was added to the policy by listing the ports again and filtering for the type:

# semanage port -l | grep ssh_port_t
ssh_port_t                     tcp      2222, 22

After adding the port definition and modifying the port on the actual SSH daemon side, restart the SSH service and the daemon should be accessible on the custom port 2222.

If you need to remove the customization, use the -dflag:

# semanage port -d -t ssh_port_t -p tcp 2222

When troubleshooting an issue with a specific service, it can be useful to disable SELinux enforcement for that specific service. Making a domain permissive means that SELinux logs policy violations for that domain but does not block any actions. This is a more targeted and secure alternative to switching the entire system to permissive mode with setenforce 0 command.

The semanage permissive command allows you to manage a list of domains that operate permissively even while the system is enforcing the policy globally. This change is persistent across reboots.

# ps -eZ | grep haproxy
system_u:system_r:haproxy_t:s0    45248 ?        00:00:00 haproxy

# semanage permissive -a haproxy_t

# semanage permissive -l

Builtin Permissive Types
...

Customized Permissive Types

haproxy_t

# semanage permissive -d haproxy_t

The semanage module command is used to manage policy modules. Some non-SELinux packages ship their independent policy modules, which enhance the rules in the main SELinux policy. These are usually installed only when the application package is installed.

Additionally, system administrators and software developers can enhance the SELinux policy with their custom set of rules, by introducing a custom policy module.

To view all modules currently installed in the policy, along with their priority and language, use the -l option. Modules included in the main policy usually have priority 100, whereas a priority of 200 suggests the module is included in a different package. Custom modules added by the user have a priority of 400 if not specified differently, for example:

# semanage module -l

Module Name               Priority  Language

abrt                      100       pp
accountsd                 100       pp
acct                      100       pp
afs                       100       pp
...

To disable a module for troubleshooting, use the -d option:

# semanage module -d MODULE_NAME

For example, to disable the container module, run:

# semanage module -d container

To verify that the module has been disabled, check the output of semodule -l. It should add a Disabled column:

# semanage module -l | grep container
container                 200       pp    Disabled

To reenable a module, run:

# semanage module -e MODULE_NAME

To permanently remove a module and all of its rules from the policy store, use the -r flag. This option is usually only needed when working with custom SELinux modules created by the user. It is not recommended or supported to remove modules that were shipped with the operating system.

# semanage module -r my-local-module