1The SELinux Userspace Security Vulnerability Handling Process 2=============================================================================== 3https://github.com/SELinuxProject/selinux 4 5This document attempts to describe the processes through which sensitive 6security relevant bugs can be responsibly disclosed to the SELinux userspace 7project and how the project maintainers should handle these reports. Just like 8the other SELinux userspace process documents, this document should be treated 9as a guiding document and not a hard, unyielding set of regulations; the bug 10reporters and project maintainers are encouraged to work together to address 11the issues as best they can, in a manner which works best for all parties 12involved. 13 14### Reporting Problems 15 16For serious problems or security vulnerabilities in the SELinux kernel code 17please refer to the SELinux Kernel Subsystem Security Policy in the link below: 18 19* https://github.com/SELinuxProject/selinux-kernel/blob/main/SECURITY.md 20 21Problems with the SELinux userspace that are not suitable for immediate public 22disclosure should be emailed to the current SELinux userspace maintainers, the 23list is below. We typically request at most a 90 day time period to address 24the issue before it is made public, but we will make every effort to address 25the issue as quickly as possible and shorten the disclosure window. 26 27* Petr Lautrbach, [email protected] 28* Nicolas Iooss, [email protected] 29 * (GPG fingerprint) E25E 254C 8EE4 D303 554B F5AF EC70 1A1D A494 C5EB 30* Jeffrey Vander Stoep, [email protected] 31* Joshua Brindle, [email protected] 32* James Carter, [email protected] 33 * (GPG fingerprint) 4568 1128 449B 65F8 80C6 1797 3A84 A946 B4BA 62AE 34* Paul Moore, [email protected] 35 * (GPG fingerprint) 7100 AADF AE6E 6E94 0D2E 0AD6 55E4 5A5A E8CA 7C8A 36* Jason Zaman, [email protected] 37 * (GPG fingerprint) 6319 1CE9 4183 0986 89CA B8DB 7EF1 37EC 935B 0EAF 38* Steve Lawrence, [email protected] 39* William Roberts, [email protected] 40* Ondrej Mosnacek, [email protected] 41 42### Resolving Sensitive Security Issues 43 44Upon disclosure of a bug, the maintainers should work together to investigate 45the problem and decide on a solution. In order to prevent an early disclosure 46of the problem, those working on the solution should do so privately and 47outside of the traditional SELinux userspace development practices. One 48possible solution to this is to leverage the GitHub "Security" functionality to 49create a private development fork that can be shared among the maintainers, and 50optionally the reporter. A placeholder GitHub issue may be created, but details 51should remain extremely limited until such time as the problem has been fixed 52and responsibly disclosed. If a CVE, or other tag, has been assigned to the 53problem, the GitHub issue title should include the vulnerability tag once the 54problem has been disclosed. 55 56### Public Disclosure 57 58Whenever possible, responsible reporting and patching practices should be 59followed, including notification to the linux-distros and oss-security mailing 60lists. 61 62* https://oss-security.openwall.org/wiki/mailing-lists/distros 63* https://oss-security.openwall.org/wiki/mailing-lists/oss-security 64