All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Add a file describing the security vulnerability handling process
@ 2022-03-25 17:30 James Carter
  2022-03-28  9:01 ` Petr Lautrbach
  0 siblings, 1 reply; 4+ messages in thread
From: James Carter @ 2022-03-25 17:30 UTC (permalink / raw)
  To: selinux; +Cc: James Carter

Add the file SECURITY.md which describes the SELinux userspace
security vulnerability handling process including who to contact.

Signed-off-by: James Carter <jwcart2@gmail.com>
---
 SECURITY.md | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 00000000..37630585
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,59 @@
+The SELinux Userspace Security Vulnerability Handling Process
+===============================================================================
+https://github.com/SELinuxProject/selinux
+
+This document attempts to describe the processes through which sensitive
+security relevant bugs can be responsibly disclosed to the SELinux userspace
+project and how the project maintainers should handle these reports. Just like
+the other SELinux userspace process documents, this document should be treated
+as a guiding document and not a hard, unyielding set of regulations; the bug
+reporters and project maintainers are encouraged to work together to address
+the issues as best they can, in a manner which works best for all parties
+involved.
+
+### Reporting Problems
+
+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.
+
+* Petr Lautrbach, plautrba@redhat.com
+* Nicolas Iooss, nicolas.iooss@m4x.org
+* Jeffrey Vander Stoep, jeffv@google.com
+* Joshua Brindle, brindle@gmail.com
+* James Carter, jwcart2@gmail.com
+* Paul Moore, paul@paul-moore.com
+* Jason Zaman, perfinion@gentoo.org
+* Steve Lawrence, slawrence@tresys.com
+* William Roberts, bill.c.roberts@gmail.com
+* Ondrej Mosnacek, omosnace@redhat.com
+
+### Resolving Sensitive Security Issues
+
+Upon disclosure of a bug, the maintainers should work together to investigate
+the problem and decide on a solution. In order to prevent an early disclosure
+of the problem, those working on the solution should do so privately and
+outside of the traditional SELinux userspace development practices. One
+possible solution to this is to leverage the GitHub "Security" functionality to
+create a private development fork that can be shared among the maintainers, and
+optionally the reporter. A placeholder GitHub issue may be created, but details
+should remain extremely limited until such time as the problem has been fixed
+and responsibly disclosed. If a CVE, or other tag, has been assigned to the
+problem, the GitHub issue title should include the vulnerability tag once the
+problem has been disclosed.
+
+### Public Disclosure
+
+Whenever possible, responsible reporting and patching practices should be
+followed, including notification to the linux-distros and oss-security mailing
+lists.
+
+* https://oss-security.openwall.org/wiki/mailing-lists/distros
+* https://oss-security.openwall.org/wiki/mailing-lists/oss-security
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] Add a file describing the security vulnerability handling process
  2022-03-25 17:30 [PATCH] Add a file describing the security vulnerability handling process James Carter
@ 2022-03-28  9:01 ` Petr Lautrbach
  2022-03-30 19:07   ` James Carter
  0 siblings, 1 reply; 4+ messages in thread
From: Petr Lautrbach @ 2022-03-28  9:01 UTC (permalink / raw)
  To: James Carter, selinux

James Carter <jwcart2@gmail.com> writes:

> Add the file SECURITY.md which describes the SELinux userspace
> security vulnerability handling process including who to contact.
>
> Signed-off-by: James Carter <jwcart2@gmail.com>

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


> ---
>  SECURITY.md | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 59 insertions(+)
>  create mode 100644 SECURITY.md
>
> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 00000000..37630585
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,59 @@
> +The SELinux Userspace Security Vulnerability Handling Process
> +===============================================================================
> +https://github.com/SELinuxProject/selinux
> +
> +This document attempts to describe the processes through which sensitive
> +security relevant bugs can be responsibly disclosed to the SELinux userspace
> +project and how the project maintainers should handle these reports. Just like
> +the other SELinux userspace process documents, this document should be treated
> +as a guiding document and not a hard, unyielding set of regulations; the bug
> +reporters and project maintainers are encouraged to work together to address
> +the issues as best they can, in a manner which works best for all parties
> +involved.
> +
> +### Reporting Problems
> +
> +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.
> +
> +* Petr Lautrbach, plautrba@redhat.com
> +* Nicolas Iooss, nicolas.iooss@m4x.org
> +* Jeffrey Vander Stoep, jeffv@google.com
> +* Joshua Brindle, brindle@gmail.com
> +* James Carter, jwcart2@gmail.com
> +* Paul Moore, paul@paul-moore.com
> +* Jason Zaman, perfinion@gentoo.org
> +* Steve Lawrence, slawrence@tresys.com
> +* William Roberts, bill.c.roberts@gmail.com
> +* Ondrej Mosnacek, omosnace@redhat.com
> +
> +### Resolving Sensitive Security Issues
> +
> +Upon disclosure of a bug, the maintainers should work together to investigate
> +the problem and decide on a solution. In order to prevent an early disclosure
> +of the problem, those working on the solution should do so privately and
> +outside of the traditional SELinux userspace development practices. One
> +possible solution to this is to leverage the GitHub "Security" functionality to
> +create a private development fork that can be shared among the maintainers, and
> +optionally the reporter. A placeholder GitHub issue may be created, but details
> +should remain extremely limited until such time as the problem has been fixed
> +and responsibly disclosed. If a CVE, or other tag, has been assigned to the
> +problem, the GitHub issue title should include the vulnerability tag once the
> +problem has been disclosed.
> +
> +### Public Disclosure
> +
> +Whenever possible, responsible reporting and patching practices should be
> +followed, including notification to the linux-distros and oss-security mailing
> +lists.
> +
> +* https://oss-security.openwall.org/wiki/mailing-lists/distros
> +* https://oss-security.openwall.org/wiki/mailing-lists/oss-security
> -- 
> 2.34.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Add a file describing the security vulnerability handling process
  2022-03-28  9:01 ` Petr Lautrbach
@ 2022-03-30 19:07   ` James Carter
  2022-04-04 19:32     ` Paul Moore
  0 siblings, 1 reply; 4+ messages in thread
From: James Carter @ 2022-03-30 19:07 UTC (permalink / raw)
  To: Petr Lautrbach; +Cc: SElinux list

On Mon, Mar 28, 2022 at 5:01 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> James Carter <jwcart2@gmail.com> writes:
>
> > Add the file SECURITY.md which describes the SELinux userspace
> > security vulnerability handling process including who to contact.
> >
> > Signed-off-by: James Carter <jwcart2@gmail.com>
>
> Acked-by: Petr Lautrbach <plautrba@redhat.com>
>

Merged.
Jim

>
> > ---
> >  SECURITY.md | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 59 insertions(+)
> >  create mode 100644 SECURITY.md
> >
> > diff --git a/SECURITY.md b/SECURITY.md
> > new file mode 100644
> > index 00000000..37630585
> > --- /dev/null
> > +++ b/SECURITY.md
> > @@ -0,0 +1,59 @@
> > +The SELinux Userspace Security Vulnerability Handling Process
> > +===============================================================================
> > +https://github.com/SELinuxProject/selinux
> > +
> > +This document attempts to describe the processes through which sensitive
> > +security relevant bugs can be responsibly disclosed to the SELinux userspace
> > +project and how the project maintainers should handle these reports. Just like
> > +the other SELinux userspace process documents, this document should be treated
> > +as a guiding document and not a hard, unyielding set of regulations; the bug
> > +reporters and project maintainers are encouraged to work together to address
> > +the issues as best they can, in a manner which works best for all parties
> > +involved.
> > +
> > +### Reporting Problems
> > +
> > +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.
> > +
> > +* Petr Lautrbach, plautrba@redhat.com
> > +* Nicolas Iooss, nicolas.iooss@m4x.org
> > +* Jeffrey Vander Stoep, jeffv@google.com
> > +* Joshua Brindle, brindle@gmail.com
> > +* James Carter, jwcart2@gmail.com
> > +* Paul Moore, paul@paul-moore.com
> > +* Jason Zaman, perfinion@gentoo.org
> > +* Steve Lawrence, slawrence@tresys.com
> > +* William Roberts, bill.c.roberts@gmail.com
> > +* Ondrej Mosnacek, omosnace@redhat.com
> > +
> > +### Resolving Sensitive Security Issues
> > +
> > +Upon disclosure of a bug, the maintainers should work together to investigate
> > +the problem and decide on a solution. In order to prevent an early disclosure
> > +of the problem, those working on the solution should do so privately and
> > +outside of the traditional SELinux userspace development practices. One
> > +possible solution to this is to leverage the GitHub "Security" functionality to
> > +create a private development fork that can be shared among the maintainers, and
> > +optionally the reporter. A placeholder GitHub issue may be created, but details
> > +should remain extremely limited until such time as the problem has been fixed
> > +and responsibly disclosed. If a CVE, or other tag, has been assigned to the
> > +problem, the GitHub issue title should include the vulnerability tag once the
> > +problem has been disclosed.
> > +
> > +### Public Disclosure
> > +
> > +Whenever possible, responsible reporting and patching practices should be
> > +followed, including notification to the linux-distros and oss-security mailing
> > +lists.
> > +
> > +* https://oss-security.openwall.org/wiki/mailing-lists/distros
> > +* https://oss-security.openwall.org/wiki/mailing-lists/oss-security
> > --
> > 2.34.1
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Add a file describing the security vulnerability handling process
  2022-03-30 19:07   ` James Carter
@ 2022-04-04 19:32     ` Paul Moore
  0 siblings, 0 replies; 4+ messages in thread
From: Paul Moore @ 2022-04-04 19:32 UTC (permalink / raw)
  To: James Carter; +Cc: Petr Lautrbach, SElinux list

On Wed, Mar 30, 2022 at 3:07 PM James Carter <jwcart2@gmail.com> wrote:
> On Mon, Mar 28, 2022 at 5:01 AM Petr Lautrbach <plautrba@redhat.com> wrote:
> >
> > James Carter <jwcart2@gmail.com> writes:
> >
> > > Add the file SECURITY.md which describes the SELinux userspace
> > > security vulnerability handling process including who to contact.
> > >
> > > Signed-off-by: James Carter <jwcart2@gmail.com>
> >
> > Acked-by: Petr Lautrbach <plautrba@redhat.com>
>
> Merged.
> Jim

Thanks everyone :)

-- 
paul-moore.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-04-04 21:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-25 17:30 [PATCH] Add a file describing the security vulnerability handling process James Carter
2022-03-28  9:01 ` Petr Lautrbach
2022-03-30 19:07   ` James Carter
2022-04-04 19:32     ` Paul Moore

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.