diff --git a/src/contents.rst b/src/contents.rst index 994dac0..859793a 100644 --- a/src/contents.rst +++ b/src/contents.rst @@ -14,6 +14,7 @@ Table of Contents contrib/coding-style contrib/tests contrib/profiling-sssd + contrib/security-policy .. toctree:: :caption: Fundamentals diff --git a/src/contrib/security-policy.rst b/src/contrib/security-policy.rst new file mode 100644 index 0000000..9667a49 --- /dev/null +++ b/src/contrib/security-policy.rst @@ -0,0 +1,152 @@ +SSSD Security Policy +#################### + +Our Commitment +************** + +SSSD takes security seriously. We are committed to maintaining the highest +level of security and trust for our users. We appreciate the security research +community's efforts in helping us identify and address vulnerabilities +responsibly. + +Supported Versions +****************** + +Only the latest release of SSSD receives regular security patches. Earlier +versions may receive critical fixes on a best-effort basis, but we cannot +guarantee back-porting to unsupported versions. + +Security Model +************** + +Security assumptions and threat model +===================================== + +SSSD is designed to read information about users, groups and other resources +from trusted servers. This data is written into a cache file for offline usage +and is made available to system services via various interfaces. + +The data received from the server is in general trusted and only sanity checks +or similar are done. This means that SSSD should be configured to use encrypted +connection (typically used by default) and the server should be verified +(typically done by default). To do this properly SSSD has to trust system +resources like e.g the system central Certificate Authority (CA) certificate +store for TLS connections. + +It is expected that the cache file is used only by SSSD and that only a +dedicated SSSD system user or the root user can access it. It is expected that +there is always sufficient disk space for operations on the cache file, if e.g. +the disk is full some functionality of SSSD might be degraded. + +.. _reporting_a_vulnerability: + +Reporting a Vulnerability +************************* + +Please see SSSD's `SECURITY.md file on GitHub +`_ as well. + +How to Report +============= + +Please report security vulnerabilities privately through one of these channels: + + - Email + - Send to: secalert@redhat.com + +Do NOT report security vulnerabilities through: + + - Public GitHub issues + - Pull requests + - Public forums or social media + +What to Include +=============== + +Please provide the following information: + + - Title: Clear, descriptive summary + - Reporter details: Your name/handle and affiliation (optional) + - Vulnerability description: Technical details of the issue + - Affected versions: Mandatory: known, affected version; Good to have: identification of all affected versions + - Reproduction steps: Minimal example to reproduce the issue + - Impact assessment: Potential exploit scenarios and severity + - Suggested fix: If you have recommendations (optional) + - Disclosure status: Whether this has been shared elsewhere + +What to Report +============== + +Please report if you have: + - Discovered a potential security vulnerability + - Found an issue but are uncertain about its security impact + - Identified vulnerabilities in dependencies not yet addressed + +What NOT to Report +================== + +The following do not qualify as security vulnerabilities: + - Automated scanner output without analysis or reproduction steps + - General support or usage questions + - Requests for help updating to newer versions + - Bugs without security implications + +Response Process +**************** + +Please see Red Hat's `Security Contacts and Procedures +`_. + +Disclosure Policy +***************** + + - We follow coordinated disclosure practices + - Fixes are typically included in the next planned release + - Critical vulnerabilities may warrant out-of-band releases + - Public disclosure occurs via Red Hat Security Advisories + - Reporters are credited unless they prefer anonymity + +Security Advisories +******************* + +Published advisories are available at: +Red Hat CVE database: `https://access.redhat.com/security/security-updates/cve?q=sssd `_ + +Safe Usage Guidelines +********************* + +To use SSSD securely: + - Keep updated: Always use supported versions + - Always use encrypted connections and verify the server with e.g. TLS or + SASL/GSSAPI + +Scope +***** + +In Scope +======== + + - SSSD codebase + - Documentation that could lead to insecure usage + +Out of Scope +============ + +- Third-party plugins or extensions +- User-implemented code +- Issues requiring physical access +- Social engineering attacks +- Denial of service through exhaustion of external resources + + + +Recognition +*********** + +We thank security researchers who help improve SSSD. Contributors are acknowledged in: + - Security advisories + +Policy Updates +************** + +This policy may be updated periodically. Suggestions for improvement can be submitted via issues or pull requests. diff --git a/src/docs/reporting-bugs.rst b/src/docs/reporting-bugs.rst index e3711ac..ce88186 100644 --- a/src/docs/reporting-bugs.rst +++ b/src/docs/reporting-bugs.rst @@ -88,4 +88,4 @@ Alternatively, ask on the ``#sssd`` channel on libera.chat. Several SSSD or Free Consider if the bug has security consequences ********************************************* -If you think you found a bug that has security impact (allows an unprivileged user to compromise SSSD or elevate privileges for instance), don't file the bug in a public bug tracker. Instead, e-mail any of the SSSD developers instead. +If you think you found a bug that has security impact (allows an unprivileged user to compromise SSSD or elevate privileges for instance), don't file the bug in a public bug tracker. Instead, please follow the steps in :ref:`Reporting a Vulnerability `.