Stability of the SELinux Policy API

RHEL has provided its system-wide SElinux policy in the form of the selinux-policy package. By default, only system services are confined by selinux-policy. The Decentralized SELinux Policy (DSP) concept introduces a decomposition of the distribution SELinux policy. RHEL still provides SELinux policies for base system components by the selinux-policy package, but components in the AppStream repository or layered products should provide their own SELinux policy as a subpackage with the -selinux suffix.

This document outlines the extent of changes in the SELinux policy API that Red Hat can introduce in a Z-stream release, between minor releases, and in a major release of RHEL. Therefore, this guideline should help you to avoid compatibility problems when you create and maintain your own SELinux policy.

The following sections list important elements of an SELinux policy with the expected periods of their stability.

When are changes introduced

You can expect a change:
* in a Z-stream release, in other words, in between minor releases (for example, in RHEL 8.1.1)
* between minor releases (for example, between RHEL 8.1 and 8.2)
* between major releases (for example, between RHEL 7.Y and RHEL 8.0)

Object classes

Classes define sets of permissions applicable for each object that policy rules comprise of. Modification entails adding or removing permission.

For example: file, dir, socket

Booleans

Booleans, also known as conditionals, are boolean variables that switch sets of policy rules on or off.

For example: httpd_read_user_content, samba_share_nfs, deny_bluetooth

Note that packages can switch boolean values during installation, and maintainers should therefore not rely on default values.

Modules

Modules are independent parts of a security policy that you can load and unload as required.

For example: container-selinux, nagios-selinux

Interfaces

Interfaces are policy macros used to interact with a given policy module, such as giving access to types defined by a module, assigning attributes, and so on.

For example: abrt_domtrans, abrt_dbus_chat, samba_read_share_files

The previous table also applies to other macros, such as patterns, except for unconfined_domain. See Types for more information about the API stability of unconfined_domain.

Types

The SELinux type is an integral component of the SELinux security label, and it is necessary for identifying the source and target of type-enforcement rules.

For example: xserver_t, vpnc_t, usr_t

The following table also applies to SELinux users and roles.

Whenever a type is renamed, an alias of the original name is created. The type can be completely removed in the next major release.

Rules

This section covers all types of SELinux policy rules: type-enforcement, Role-Based Access Control (RBAC), Multi-Level Security (MLS) rules, except for file-context rules.

The most common rules are type enforcement Allow rules, which describe how subjects (processes) interact with objects (files, sockets, parts of memory, and so on) and each other.

For example:
* allow httpd_t krb5_conf_t:file { getattr ioctl lock open read };
* allow httpd_t httpd_t:dbus send_msg;
* allow svirt_t svirt_image_t:file map;

File contexts

File-context rules together with file-context equivalencies describe how file-system objects should be labeled.

For example:
* /sys(/.*)? system_u:object_r:sysfs_t:s0
* /mnt(/[^/]*)? -d system_u:object_r:mnt_t:s0
* /bin/.* system_u:object_r:bin_t:s0

Port contexts

Port-context statements serve for assigning labels to port and protocol pairs.

For example:
* http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000
* ssh_port_t tcp 22

Disclaimer

In RHEL 8, several packages that are not reviewed by the SELinux team influence the distribution policy. Therefore, changes introduced by those packages do not necessarily adhere to this document. That said, we are currently working on ways to standardize SELinux-related efforts in RHEL packages, which should make this document applicable for all such packages in the future.

The SELinux team strives to ensure that policy-related changes strictly follow these guidelines. However, critical security CVEs may force us to introduce changes that do not adhere to this document. We will document all such deviations.

Note that policy modules for packages from repositories that are not supported in RHEL, such as Extra Packages for Enterprise Linux (EPEL), RPM Fusion, and so on, can be removed at any time.