James Carter <jwcart2@xxxxxxxxx> 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@xxxxxxxxx> Acked-by: Petr Lautrbach <plautrba@xxxxxxxxxx> > --- > 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@xxxxxxxxxx > +* Nicolas Iooss, nicolas.iooss@xxxxxxx > +* Jeffrey Vander Stoep, jeffv@xxxxxxxxxx > +* Joshua Brindle, brindle@xxxxxxxxx > +* James Carter, jwcart2@xxxxxxxxx > +* Paul Moore, paul@xxxxxxxxxxxxxx > +* Jason Zaman, perfinion@xxxxxxxxxx > +* Steve Lawrence, slawrence@xxxxxxxxxx > +* William Roberts, bill.c.roberts@xxxxxxxxx > +* Ondrej Mosnacek, omosnace@xxxxxxxxxx > + > +### 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
