The purpose of this document is to start a discussion around how a more formal NixOS security team could operate. Its primary focus is to spur discussion.
Who is the target audience for this? Who are the stakeholders? Who votes/approves/blesses processes/procedures such that they become official?
From a high level, there are three separate security domains that could fall under this group. Briefly:
- Incident Response: How we respond to a security issue on NixOS assets, or when unauthorized code ends up in our distribution and potentially on our user's systems. In other words, when we're a part of a supply-chain attack.
- Security Subject Matter Experts (SMEs): Provide a security architecture PoV for members of the NixOS project. Helping developers and maintainers find better ways to secure our end-user's installations. (Likely NixOS specific).
- Vulnerability Management: Monitoring, Instrumenting, Driving remediation of packages that are in nixpkgs. The primary aim being to help NixOS developers and maintainers reduce the window between disclosure and remediation as much as possible.
We suggest starting with Vulnerability Management as it is the domain we assess to provide the best return on investment for our end users per volunteer hour spent.
In order to create a roadmap we suggest mapping the inputs and outputs of the team. From there, we can start proposing processes to facilitate this with a focus on reducing volunteer pain.
Primary focus for this domain is to assist the greater project in reducing Dwell Time (time between notification and fixes applied/distributed) for both stable and unstable.
- Private Notifications (NixOS Specific). Either via github issues, or notifications via security@nixos.org
- Issues that maintainers / developers have tagged "security".
- Embargoed notifications. We should endevor to join embargoed notification lists such as distros@openwall so we get a head-start.
- Mapping of NVD/CVE database to nixpkgs stable/unstable. (We have some processes that do some of this already. Andi- has some work in this area already, as well as vulnix - repology also appears to do this). Automation Awesome™
- Other?
- Private Staged PRs for when stuff is still embargoed.
- Measuring the "Dwell Time" between vulnerability notification and fixes applied.
- Measuring the NVD/nixpkgs mapping and pushing those values down.
- Ensuring that vulnerabilities when fixed in unstable get considered for back-porting to stable.
Ideally, most of the work above would be automated.
Note: Processing private/embargoed issues vs issues that are public require a different process. There are enumerated confidentiality requirements for membership of said groups. Although we believe that it's important, it should wait until we have some more of the basics codified.
- Vulnerability is triaged and the following assessed: a. The impact of the vulnerabilty to the end-user. b. Is the remediation as simple as a version-bump?
- Depending on the Security vs Operational Risk, a decision can be made as to who and how the remediation is applied. An aspirational SLA to set expectations would be a good thing. For example: A network-exploitable vulnerability which provides an attacker remote code execution AND has a published exploit should be treated differently than a local privilege escallation.
- Reporting / Facilitation of remediation.
In an ideal world, all of the above would be able to be automated. It's always better to manage the systems that manage the process than to manage the process directly.
There has been some excellent work done automatically mapping CVEs and opening issues to remediate them. However, the risk in automating the input of your process without having efficient tooling for managing the work risks team burnout.
The current state of the security label:
| Query | Count |
|---|---|
| is:open label:"1.severity: security" | 709 |
| is:open label:"1.severity: security" comments:0 | 458 |
In order to reduce the workload a human has to do during the process, here are some tooling suggestions:
- ckauhaus' excellent script already opens issues and tags them with the CVE and CVSS score. A command-line tool that allows us to search, sort, and filter based on the CVSS score would make life a lot easier.
- Ask ckauhaus to add to his automation the CVSS calculation string so that our tooling can also filter on things like Attack Vector (AC), Attack Complexity (AC), or User Interaction (UI).
- A process that goes behind ckauhaus' process and: a. Attempts to link their Issues to matching PRs. b. Flag for potential backport when only fixed in unstable. c. Flag for closure when PRs are merged that match the NVD remediation requirements.
__red__: I've not worked with the github API before so I'm going to take a stab this evening at trying to see if I can get some kind of cli application running - so even if none of these proposals are accepted, I can start to plow through some of this backlog.