[PATCH v2] SECURITY.md: Codify the maintainer process
Stephen Smalley <[email protected]> Mon, 3 Aug 2026 13:39:52 -0400
| Newsgroups | org.kernel.vger.selinux |
|---|---|
| Message-ID | <[email protected]> |
From: Jason Zaman <[email protected]> Since security issues are quite rare, best to codify the processes so when they come along we can fall back to this and don't forget any steps. Signed-off-by: Jason Zaman <[email protected]> Signed-off-by: Stephen Smalley <[email protected]> --- v2 makes the changes suggested by reviewers and drops the RFC/draft language. SECURITY.md | 44 +++++++++++++++++++++++++++++++++++++++----- 1 file changed, 39 insertions(+), 5 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 49c40e97..52ab863c 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -13,16 +13,23 @@ involved. ### Reporting Problems +Note that issues that depend on attacker-controlled policy can be +reported as regular bugs to the public [email protected] mailing +list and do not need to follow this process. + For serious problems or security vulnerabilities in the SELinux kernel code please refer to the SELinux Kernel Subsystem Security Policy in the link below: * https://github.com/SELinuxProject/selinux-kernel/blob/main/SECURITY.md -Problems with the SELinux userspace that are not suitable for immediate public -disclosure should be emailed to the current SELinux userspace maintainers, the -list is below. We typically request at most a 90 day time period to address -the issue before it is made public, but we will make every effort to address -the issue as quickly as possible and shorten the disclosure window. +Problems with the SELinux userspace that are not suitable for +immediate public disclosure should be reported using +[GitHub private vulnerability reporting](https://github.com/SELinuxProject/selinux/security) +or emailed to the current SELinux userspace maintainers - the list is +below. We typically request at most a 90 day time period to address +the issue before it is made public, but we will make every effort to +address the issue as quickly as possible and shorten the disclosure +window. * Petr Lautrbach, [email protected] * James Carter, [email protected] @@ -35,6 +42,10 @@ the issue as quickly as possible and shorten the disclosure window. * (GPG fingerprint) 6319 1CE9 4183 0986 89CA B8DB 7EF1 37EC 935B 0EAF * Ondrej Mosnacek, [email protected] +If unsure about whether an issue is in kernel or userspace, feel free +to send it to both the kernel and userspace maintainers and the +maintainers will handle it internally. + ### Resolving Sensitive Security Issues Upon disclosure of a bug, the maintainers should work together to investigate @@ -57,3 +68,26 @@ lists. * https://oss-security.openwall.org/wiki/mailing-lists/distros * https://oss-security.openwall.org/wiki/mailing-lists/oss-security + +### Maintainer Process + +This is the process maintainers will follow upon receiving a security notification. + +1. Make sure all appropriate SELinux maintainers are notified. Regardless of + which maintainer was initially contacted, others should be looped in. This + may also include the kernel maintainers if relevant to the issue. +2. After an initial review of the issue, maintainers will agree on one person + to be main point of contact. The response to the initial mail may come from a + different maintainer. If the initial mail was PGP signed/encrypted, the + replies will also be PGP signed/encrypted with one of the above keys. +3. Maintainers will work together in private to verify and fix the issue. For + larger fixes, this might involve a github private fork within a draft github + security advisory. +4. Maintainers will prepare the fix as soon as reasonable. Maintainers may + invite the reporter to the draft security advisory or private fork to help + verifying the fix. +5. We will aim to release the fix publicly quickly, but may request an embargo + period up to 90 days if the complexity of the issue requires it or if + severity of the issue requires coordinated rollout amongst distros. +6. Public disclosure will involve pushing the fix to the public repo and + publishing the security advisory on Github and to the mailing list. -- 2.55.0