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

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

[Stephen Smalley]

From: Jason Zaman <jason@perfinion.com>

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 <jason@perfinion.com>
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
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 selinux@vger.kernel.org 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, plautrba@redhat.com
 * James Carter, jwcart2@gmail.com
@@ -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, omosnace@redhat.com
 
+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

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

[Stephen Smalley]

On Mon, Aug 3, 2026 at 1:40 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> From: Jason Zaman <jason@perfinion.com>
>
> 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 <jason@perfinion.com>
> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>

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 selinux@vger.kernel.org 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, plautrba@redhat.com
>  * James Carter, jwcart2@gmail.com
> @@ -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, omosnace@redhat.com
>
> +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
>

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

[Petr Lautrbach]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Mon, Aug 3, 2026 at 1:40 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>>
>> From: Jason Zaman <jason@perfinion.com>
>>
>> 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 <jason@perfinion.com>
>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>

Acked-by: Petr Lautrbach <lautrbach@redhat.com>

>
> 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 selinux@vger.kernel.org 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, plautrba@redhat.com
>>  * James Carter, jwcart2@gmail.com
>> @@ -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, omosnace@redhat.com
>>
>> +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
>>

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

[Stephen Smalley]

On Mon, Aug 10, 2026 at 5:47 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>
> > On Mon, Aug 3, 2026 at 1:40 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> >>
> >> From: Jason Zaman <jason@perfinion.com>
> >>
> >> 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 <jason@perfinion.com>
> >> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>
> Acked-by: Petr Lautrbach <lautrbach@redhat.com>

Thanks, merged.