Re: [PATCH v2] SECURITY.md: Codify the maintainer process

On Mon, Aug 3, 2026 at 1:40 PM Stephen Smalley
<[email protected]> wrote:
>
> 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]>

Sorry to nag but would like at least one other selinux maintainer to
ack this before merging.

> ---
> 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
>