checkpolicy

Overview

checkpolicy is part of the upstream SELinux userspace toolset. It provides build-time tooling for working with SELinux policy sources, including compilation of a text policy source into the kernel policy format and inspection of compiled policy data. The upstream SELinux project describes these tools as part of the userspace that complements SELinux in the Linux kernel and is used by Linux distributions. (github.com)

In a Linux distribution, this package exists so maintainers, policy developers, and other administrators who build SELinux policy from source have the compiler and related inspection utilities available in a packaged form. Normal end-user systems may not need it, but it is useful wherever policy is developed, rebuilt, tested, or analyzed. (github.com)

Purpose and typical use cases

Typical use cases for checkpolicy include:

• compiling SELinux policy sources into kernel policy format;
• checking policy data during policy development and distribution integration;
• inspecting compiled policy content with the utilities shipped by this package;
• supporting packaging workflows that need to rebuild or validate policy artifacts before delivery. (github.com)

Typical users include:

• distribution and package maintainers;
• SELinux policy developers;
• system administrators who work on local policy changes;
• security engineers who review or test policy behavior;
• CI/CD maintainers running policy build or validation jobs. (github.com)

Upstream project

This package is sourced from the upstream SELinux userspace project maintained by the SELinuxProject community. The upstream wiki states that the project provides userspace libraries and tools that complement SELinux in the Linux kernel, including policy compilation and policy management tooling. (github.com)

For checkpolicy specifically, the upstream manual page documents the command as the tool used to compile a kernel policy from a policy source file. NiceOS maintainers should verify any command-line details against the current upstream man page when updating packaging or documentation. (man7.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to track upstream inputs;
• METADATA/ — repository metadata maintained by the packaging workflow;
• SBOM/ — software bill of materials material kept for distribution tracking and review.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps integrity metadata in SOURCES/ manifests so the expected source inputs can be verified without committing large payloads into Git. NiceOS maintainers should treat the manifest data as the source of truth for packaging integrity checks.

Source storage and integrity policy

The repository does not store the full upstream source archive in Git. This keeps the repository smaller and avoids duplicating large tarballs in version control.

Source integrity is tracked through manifest files in SOURCES/. When updating the package, maintainers should confirm that the manifest entries match the intended upstream sources and that any regenerated metadata is consistent with the packaging inputs.

If the update path changes how upstream sources are fetched or unpacked, maintainers should verify whether the spec file, source manifests, patch set, or SBOM content also needs to be refreshed.

NiceOS maintenance notes

Before updating checkpolicy, NiceOS maintainers should review the following:

• confirm the upstream release notes and changelog for any behavior changes relevant to policy compilation;
• check whether the spec file needs adjustments for new build requirements or changed install paths;
• verify whether any patch still applies cleanly or should be dropped;
• inspect SOURCES/ manifests after source refreshes;
• review SBOM/ entries if the packaging process records source or component metadata there;
• run the package build and any policy-related smoke checks used by the repository.

Risks to consider:

• policy compiler behavior may change in ways that affect local policy builds;
• output differences can affect downstream policy packages or automated tests;
• regenerated metadata may need to stay aligned across SPECS/, SOURCES/, and SBOM/;
• build failures may only appear when policy sources are compiled in the target environment.

If any of these points are uncertain for a specific update, NiceOS maintainers should verify them before relying on the package in release workflows.

Build and verification checklist

Suggested checklist for RPM maintainers:

1. Review the upstream release notes and the relevant packaging changes.
2. Confirm that the SOURCES/ manifests match the intended upstream inputs.
3. Check whether the spec file needs edits for dependency, path, or build-system changes.
4. Rebuild the SRPM and binary RPMs in a clean environment.
5. Run the package test or smoke-test steps used by the repository.
6. Verify that installed files and generated artifacts match expectations.
7. Confirm that SBOM/ content, if maintained here, still reflects the packaged inputs.
8. Review build logs for warnings that could indicate policy-format or tooling changes.
9. If the package ships documentation or man pages, confirm that they still describe the current upstream behavior.

References

• SELinux Userspace wiki
• SELinux Userspace project repository
• checkpolicy(8) manual page

Russian documentation

See README_RU.md.

Dist-git repository notes

• Package repository: rpms/checkpolicy
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.