2022-03-25 18:06:22 +01:00
|
|
|
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
|
2022-10-13 16:29:41 +02:00
|
|
|
* (GPG fingerprint) E25E 254C 8EE4 D303 554B F5AF EC70 1A1D A494 C5EB
|
2022-03-25 18:06:22 +01:00
|
|
|
* Jeffrey Vander Stoep, jeffv@google.com
|
|
|
|
|
* Joshua Brindle, brindle@gmail.com
|
|
|
|
|
* James Carter, jwcart2@gmail.com
|
2022-10-13 16:29:41 +02:00
|
|
|
* (GPG fingerprint) 4568 1128 449B 65F8 80C6 1797 3A84 A946 B4BA 62AE
|
2022-03-25 18:06:22 +01:00
|
|
|
* Paul Moore, paul@paul-moore.com
|
2022-09-22 22:32:22 +02:00
|
|
|
* (GPG fingerprint) 7100 AADF AE6E 6E94 0D2E 0AD6 55E4 5A5A E8CA 7C8A
|
2022-03-25 18:06:22 +01:00
|
|
|
* Jason Zaman, perfinion@gentoo.org
|
2022-10-13 16:29:41 +02:00
|
|
|
* (GPG fingerprint) 6319 1CE9 4183 0986 89CA B8DB 7EF1 37EC 935B 0EAF
|
2022-03-25 18:06:22 +01:00
|
|
|
* 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
|
