Re: [PATCH 3/3] RFC: SECURITY.md: Rough draft of codifying the maintainer process

On Thu, Jul 23, 2026 at 9:30 AM Stephen Smalley
<[email protected]> wrote:
>
> On Thu, Jul 23, 2026 at 2:25 AM Jason Zaman <[email protected]> wrote:
> >
> > Since security issues are quite rare, best to codify the processes so
> > when they come along we can fall back to this and dont forget any steps.
>
> don't or do not
>
> >
> > Signed-off-by: Jason Zaman <[email protected]>
> > ---
> >  SECURITY.md | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/SECURITY.md b/SECURITY.md
> > index 49c40e97..145a2714 100644
> > --- a/SECURITY.md
> > +++ b/SECURITY.md
> > @@ -35,6 +35,9 @@ 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
> > +to any and the maintainers will handle it internally.
>
> I'd recommend sending to both rather than any to avoid potential loss/delay.
> We should also mention that private vulnerability reporting is now
> enabled on GitHub,
> so another option is to submit via:
> https://github.com/SELinuxProject/selinux/security/advisories

We may also want to add something like the following to SECURITY.md:
Bugs in libsepol that only affect policy compilers (checkpolicy,
checkmodule, secilc) are not considered
security vulnerabilities. The policy compilers are typically run
without any privileges and attackers who
can feed them arbitrary inputs can do more interesting things. We will
fix such bugs but will not create
security advisories for them.

>
> > +
> >  ### Resolving Sensitive Security Issues
> >
> >  Upon disclosure of a bug, the maintainers should work together to investigate
> > @@ -57,3 +60,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.54.0
> >
> >