|
| 1 | +# credentialsd Security Policy |
| 2 | + |
| 3 | +This policy outlines our intentions for addressing security issues and practices |
| 4 | +for security researchers investigating this project. |
| 5 | + |
| 6 | +## Submitting Vulnerability Reports |
| 7 | + |
| 8 | +Since this project handles very sensitive data, we take security seriously. If |
| 9 | +you have discovered a security vulnerability in this project, please report it |
| 10 | +to us privately via the process below. |
| 11 | + |
| 12 | +We use GitHub for private vulnerability disclosure. To report a vulnerability: |
| 13 | + |
| 14 | +1. Go to [Security > Advisories > New draft security advisory][new-advisory]. |
| 15 | +2. Fill out the report and submit the draft. |
| 16 | +3. The maintainers will be privately notified about the advisory and get back to |
| 17 | + you. |
| 18 | + |
| 19 | +[new-advisory]: https://github.com/linux-credentials/credentialsd/security/advisories/new |
| 20 | + |
| 21 | +## Expected Response |
| 22 | + |
| 23 | +We will acknowledge the receipt of the report immediately and will work with |
| 24 | +you. We seek to investigate issues within 30 days. |
| 25 | + |
| 26 | +If the issue is confirmed upon investigation, we will collaborate with you to |
| 27 | +remediate the vulnerability. Depending on the severity or developer |
| 28 | +availability, we may request more time to remediate the issue before allowing |
| 29 | +public disclosure. |
| 30 | + |
| 31 | +# Supported Releases |
| 32 | + |
| 33 | +We only support the latest published release. We may backport patches when |
| 34 | +possible to help users running on distributions that package older versions of |
| 35 | +our software. |
| 36 | + |
| 37 | +## Threat Model |
| 38 | + |
| 39 | +We do not currently have a formally defined threat model; we will continue to |
| 40 | +document it over time. However, the basic security guarantees we would like to |
| 41 | +achieve are defined below. |
| 42 | + |
| 43 | +Please note, that if you believe you have discovered a security problem outside |
| 44 | +of this scope, we still want to know about it! We would still like to discuss |
| 45 | +the issue privately, but we may not decide to address it within the response |
| 46 | +time described above. |
| 47 | + |
| 48 | +### Definitons |
| 49 | + |
| 50 | +- _privileged client_: A client that is allowed to make requests for credentials |
| 51 | + for any origin. |
| 52 | +- _unprivileged client_: A client that is allowed to make requests for |
| 53 | + credentials for only a preconfigured set of origins. |
| 54 | + |
| 55 | +### Scope |
| 56 | + |
| 57 | +- Privileged clients may request credentials via this service[^1] for any origin. |
| 58 | +- The list of privileged clients cannot change without: |
| 59 | + - `root` privileges, or |
| 60 | + - user consent[^2] |
| 61 | +- The list of unprivileged clients cannot change without: |
| 62 | + - `root` privileges, or |
| 63 | + - user consent[^2] |
| 64 | + |
| 65 | +[^1]: |
| 66 | + Various systems may allow users to interact with authenticators directly |
| 67 | + (e.g. allowing unrestricted permission to USB devices or Bluetooth service |
| 68 | + data), so those are out of scope. |
| 69 | + |
| 70 | +[^2]: |
| 71 | + In the future we may offer stricter configuration where privileged clients |
| 72 | + must include permission metadata be signed by a trusted party. |
0 commit comments