SELinux Userspace: C libraries and tools for Linux policy administration

What SELinux userspace actually provides

This repository addresses a specific gap between the SELinux mechanisms built into the Linux kernel and the software administrators need to use them. The README describes SELinux as Mandatory Access Control, or MAC, that adds access-control decisions beyond Linux Discretionary Access Controls, or DAC. DAC commonly bases access on ownership, permissions, and related filesystem properties. SELinux adds policy rules and security labels that can restrict access more precisely according to the identity and role of processes and resources.

The repository is not a complete Linux distribution and it does not replace the kernel's SELinux implementation. It contains the sources for SELinux utilities and system libraries used to configure and manage an SELinux-based system. The top-level layout separates major components such as libselinux, libsepol, libsemanage, checkpolicy, secilc, policycoreutils, mcstrans, and language-binding directories. That separation matters for engineers because a distribution may use some libraries and commands while compiling or shipping others differently.

The intended users are Linux distributions and administrators rather than application developers looking for a small library to add an access check. Distribution maintainers may build these sources for system packages, while policy authors and system integrators may use the policy build, analysis, management, and utility components. The README also directs bug reports and patches to the [email protected] mailing list. Its documentation points to the SELinux Userspace wiki for additional information, but the repository excerpt does not document a complete first-use command for a freshly installed system.

libsepol, libselinux, and policy processing

The repository's structure shows a layered userland design. libsepol is the policy-focused library used by policy construction and analysis components. libselinux is the interface used by SELinux-aware software and administration utilities to interact with the runtime security environment. libsemanage sits above these foundations and manages policy-related state, while checkpolicy, checkmodule, and secilc provide policy compilation and checking functionality.

The README explains that libsepol affects several parts of the system. It constrains the policy build toolchain, including checkpolicy, checkmodule, and secilc. It also constrains libselinux and its users, including the inability to downgrade a policy file below the supported minimum and the inability of libsemanage to read an older binary policy module. Policy analysis tools such as setools are subject to the same boundary, even though setools is not listed as a top-level entry.

This means the relevant compatibility decision is not limited to whether a C program compiles. A policy tool may reject input because the policy version is too old, or a system upgrade may leave binary modules that the current libraries cannot read. The source layout also includes optional subdirectories controlled by OPT_SUBDIRS, including dbus, gui, mcstrans, python, restorecond, sandbox, and semodule-utils. A distribution can therefore make packaging and dependency decisions at the component level rather than treating the repository as one indivisible binary.

Kernel and modular policy version boundaries

SELinux userspace has explicit compatibility floors. The minimum supported kernel version is Linux v4.3, matching the minimum supported kernel policy version carried by libsepol. The minimum supported kernel policy version is 30, first shipped with libsepol 2.5, Linux v4.3, and Xen 4.6. The minimum supported modular policy version is 18, first shipped with libsepol 2.7, userspace release 20170804.

The README says libsepol dropped support for kernel policy versions older than 30 starting with libsepol 3.12. It also dropped support for modular policies older than 18 at that point. The listed 3.11 release therefore belongs to the same userland project series, but the exact library version and its policy-version behavior must be checked when deploying a specific package set. The repository description identifies 3.11 as the SELinux userspace release, while the Makefile builds the component directories rather than presenting a single documented application command.

These limits affect more than development machines. Older binary modules can be carried through a system upgrade, and the README specifically notes that a modular-policy minimum increase can prevent reading and using modules built under an older release. Raising the kernel policy minimum can also prevent generating, loading, or analyzing policies for older Linux kernels or Xen hypervisors. Android is mentioned as remaining on kernel policy version 30 and as not using binary policy modules, which is a separate compatibility path from Linux distributions that use modular policies.

Building the C libraries and policy tools on Fedora

The README gives Fedora build dependencies for the C libraries and programs. It does not present a complete installation tutorial for deploying SELinux on an existing Linux host. For developers working with the source tree, the following commands are the repository's stated build interface. The first command installs the Fedora development packages needed by the C components. The second handles Python and Ruby binding dependencies.

dnf install \
    audit-libs-devel \
    bison \
    bzip2-devel \
    CUnit-devel \
    diffutils \
    flex \
    gcc \
    gettext \
    glib2-devel \
    make \
    libcap-devel \
    libcap-ng-devel \
    pam-devel \
    pcre2-devel \
    xmlto

This should provide the documented prerequisites for compiling the libraries and programs. The README groups Python and Ruby binding dependencies separately, so a distribution build that includes those bindings should install those packages as well.

dnf install \
    python3-build \
    python3-devel \
    python3-pip \
    python3-setuptools \
    python3-wheel \
    ruby-devel \
    swig

The top-level Makefile exposes `make`, `make install`, `make test`, `make clean`, and related targets, each of which is applied to the listed subdirectories. The exact output depends on the selected optional subdirectories and the host system. The README does not document a first command for checking a loaded SELinux policy, so an installation tutorial should not invent one.

Packaging, maintenance, and upgrade boundaries

SELinux libraries and tools are packaged by several Linux distributions, including Alpine Linux, Arch Linux, Buildroot, Debian and Ubuntu, Gentoo, Fedora, RHEL, SLES, openSUSE, and Yocto Project. That distribution availability is an important distinction from a standalone application. It means system integration, policy packaging, kernel compatibility, and release engineering belong to the adopting distribution as much as to this repository.

The repository is not archived. Its last push was on 2026-10-14. The recent release list includes 3.11, released on 2026-07-01, plus 3.11-rc2 and 3.11-rc3 releases earlier in June. Those dates indicate recent repository activity and release work. They do not by themselves establish that every downstream distribution will package the latest release immediately.

Upgrade cost is most visible in policy compatibility. A distribution that increments the kernel policy minimum may need to stop generating policies for older kernels. A modular policy minimum change may invalidate binary modules that were carried forward across upgrades. Build dependencies also span C libraries, Python, Ruby, SWIG, and several distribution-specific development packages. The source Makefile uses strict compiler warnings in its default build, including `-Werror`, so downstream toolchain differences can affect source builds.

The repository states that its software complements kernel-integrated SELinux features and is used by Linux distributions. The `LICENSE` file is identified as a custom license that GitHub cannot classify. That licensing detail should be reviewed directly in the repository before redistributing binaries or incorporating the code into another product. No legal conclusion can be drawn from the repository description alone.

Why DAC is a different access-control approach

Linux DAC is the relevant alternative visible in the project's documentation. DAC evaluates access through traditional permission information associated with users, groups, and filesystem objects. SELinux userspace complements the kernel's MAC system, where policy can express additional restrictions beyond those permissions.

The practical difference is therefore control policy location and granularity. DAC is sufficient when ownership and permission bits express the required boundary. SELinux is relevant when administrators need policy-driven restrictions based on process identity, role, labels, and security context. The README says SELinux provides administrators with more granular access control than DAC, but it does not claim that MAC replaces DAC. The two mechanisms coexist in the Linux security model.

The choice is not simply a question of which project has more features. A Linux distribution that does not run SELinux or does not meet the documented kernel and policy-version requirements cannot simply compile these tools and assume that mandatory access control is active. Conversely, a distribution already committed to SELinux needs compatible libraries and policy tooling even when the application-facing security behavior is mostly managed by packaging. The repository is best understood as infrastructure for that operating-system security model, not as a replacement for the kernel or for distribution packaging.

Editorial conclusion

Adopt SELinuxProject/selinux when you are maintaining SELinux support or building policy tools for a compatible Linux system. Do not treat it as a standalone security product for older kernels or an unsupported modular-policy baseline. Check the distribution packaging, kernel policy version, modular policy version, custom LICENSE terms, and the exact version of the userland release before building or upgrading it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. SELinuxProject/selinux on GitHub