Merge pull request #93 from linux-credentials/security-policy

Define security policy

Author: iinuwa

README.md

@@ -151,6 +151,10 @@ Alternatively, lock out the credential based on incorrect attempts.
 - authenticator-rs
 - webauthn-rs
 
+# Security Policy
+
+See [SECURITY.md](/SECURITY.md) for our security policy.
+
 # License
 
 See the [LICENSE.md](LICENSE.md) file for license rights and limitations (LGPL-3.0-only).

SECURITY.md

@@ -0,0 +1,84 @@
+# credentialsd Security Policy
+
+Since this project handles very sensitive data, we, the maintainers of
+credentialsd, take security seriously. This policy outlines our intentions for
+addressing security issues and practices for security researchers investigating
+this project.
+
+## Submitting Vulnerability Reports
+
+If you have discovered a security vulnerability in this project, please report it
+to us privately via the process below.
+
+We use GitHub for private vulnerability disclosure. To report a vulnerability:
+
+1. Go to [Security > Advisories > New draft security advisory][new-advisory].
+2. Fill out the report and submit the draft.
+3. The maintainers will be privately notified about the advisory and get back to
+   you.
+
+[new-advisory]: https://github.com/linux-credentials/credentialsd/security/advisories/new
+
+## Expected Response
+
+We aim to acknowledge the receipt of the report as soon as possible and will
+work with you. We seek to investigate issues within 30 days.
+
+If the issue is confirmed upon investigation, we will collaborate with you to
+remediate the vulnerability. Depending on the severity or developer
+availability, we may request more time to remediate the issue before
+public disclosure.
+
+# Supported Releases
+
+We only support the latest published release. We may backport patches when
+possible to help users running on distributions that package older versions of
+our software.
+
+# Threat Model
+
+We do not currently have a formally defined threat model; we will continue to
+document it over time. However, the basic security guarantees we would like to
+achieve are defined below.
+
+Please note, that if you believe you have discovered a security problem outside
+of this scope, we still want to know about it! We would still like to discuss
+the issue privately, but we may decide to address it beyond the response
+time described above.
+
+## Definitons
+
+- _privileged client_: A client that is allowed to make requests for credentials
+  for any origin.
+- _unprivileged client_: A client that is allowed to make requests for
+  credentials for only a preconfigured set of origins.
+
+## Scope
+
+Here is the current list of items that are in scope:
+
+- Privileged clients may request credentials via this service[^1] for any origin.
+- The list of privileged clients cannot change without:
+  - `root` privileges, or
+  - user consent[^2]
+- The list of unprivileged clients cannot change without:
+  - `root` privileges, or
+  - user consent[^2]
+
+We implicitly trust the kernel and D-Bus, so any attacks that exploit those are
+out of scope for this project.
+
+Some other attacks that are explicitly out of scope are those that require:
+
+- physical access
+- direct access to authenticators
+- root privilege escalation
+
+[^1]:
+    Various systems may allow users to interact with authenticators directly
+    (e.g. allowing unrestricted permission to USB devices or Bluetooth service
+    data), so those are out of scope.
+
+[^2]:
+    In the future we may offer a stricter guarantee that privileged clients
+    must include permission in application metadata signed by a trusted party.