Start v0.2 of Principles for Package Repository Security

[steiza]

This is where we can collect feedback from the v0.1 release, as well as pick up feedback we didn't get to in #37.

[gmollett]

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim:

Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..)

Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time.

Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

[carols10cents]

The "Authorization" section says:

Authorization

Applies to: package repositories that have user accounts and accept built packages.

but I'm not sure that this section only applies to repositories that accept built packages, unless I'm misunderstanding something.

Crates.io accepts source code, not built packages, but we definitely have API tokens for publishing that code, the tokens can have different permissions associated with them, and we integrate with GitHub's secret scanning. Perhaps this should say "Applies to: package repositories that have user accounts with associated API tokens, especially if the repository accepts built packages" or similar?

[carols10cents]

General Capabilities Level 1 has this guideline:

• The package repository has published a vulnerability disclosure policy allowing security researchers to identify and report vulnerabilities affecting the package repository, and receive legal safe harbor when doing so within the requirements of the policy. The package repository should strive to remediate reported vulnerabilities within 90 days.

which is for the security policy of the package registry itself. The registry could also be surfacing information in its UI about the security/vulnerability policy of each package. For example, this issue is where we're discussing possible improvements to crates.io's UI to display security information about each package. I think this would be a useful guideline to add, perhaps in Level 2 as it feels similar to "The package repository warns of known security vulnerabilities in dependencies in the package repository UI" to me?

[gtewallace]

Thank you to the authors for putting this set of Principles out!

An aspect of package security that I did not see, but may have missed, relates to containing, and protecting users from, malware or malicious/rogue code that makes it through. Here's how the FreeBSD package management system does it. (All of this is BSD licensed so, with porting, should be replicable by others.)

• Post-install process reaper: FreeBSD has a "reaper" feature provided by pkg for all installed packages. This reaper is responsible for terminating any processes that are started by the package during the post-installation phase. By killing these processes after installation, the reaper ensures that any potentially malicious or unintended processes are promptly terminated, reducing the window of opportunity for exploitation.

• Containment of packages: Poudriere, the FreeBSD bulk package builder and port test system, utilizes jails and Capsicum to mitigate the potential harm of malicious packages.

  • Jails are a feature of FreeBSD that allow for the creation of isolated environments within the operating system. When Poudriere builds packages, it does so within these isolated jails. This isolation prevents a malicious package from affecting the broader system. Even if a package were to contain malicious code, its impact would be limited to the jail in which it operates, minimizing the damage it can cause to the overall system.
  • Capsicum is a lightweight capability-based sandboxing framework. It restricts the capabilities of processes, reducing their ability to cause harm if compromised. Poudriere utilizes Capsicum to further enhance security by sandboxing the processes involved in building and managing packages. This limits the scope of potential damage that could be caused by a malicious package or by vulnerabilities in the package building process.
  • Packages are always built in a clean room. E.g. there is one jail for distfiles and patches, which are cryptographically checked. Once it passes, the jail is disconnected from the network and only then moves on to build as a nobody user with no network or OS access.

[phatgeek]

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim:

Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..)

Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time.

Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc?

[di]

(Note that there is some discussion about this on #40 as well)

[phatgeek]

I'm curious about specifying TOTP for authentication, which if I understand correctly is based on shared symmetric secrets. A very sophisticated adversary might make use of this to circumvent authentication (by obtaining and using the database of secrets to impersonate authorized users). Perhaps SMS is in this regard superior, even though it isn't cryptographic. Maybe FIDO2 is a better recommendation? OAUTH2 with TOTP is intended to support delegation, not authentication, per se. Please kindly correct me if I'm mistaken.

[di]

@phatgeek The current version of the doc does recommend WebAuthn (part of FIDO2) as a Level 2 principle:

The package repository supports MFA via phishing-resistant means such as WebAuthn.

The primary motivator here is that TOTP is phishable and WebAuthn is not, but I think the fact that TOTP requires storing secrets, while WebAuthn only requires storing public keys, would be a valid thing to include here as well.

[gmollett]

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim:
Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..)
Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time.
Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc?

You want both imo. They are related but different things.

[phatgeek]

Something I see missing is around the closely linked subjects of package integrity and non-repudiation. I think these are important things to consider in any package management ecosystem maturity rating. I'll take a quick stab at an idea of the levels here, but it's probably a worthwhile topic for discussion rather than taking these verbatim:
Level 1: Basic integrity verification is done at the package level via simple manually verifiable checksums. Authenticity of the repository is established via standard transport layer mechanisms (SSL/TLS etc..)
Level 2: Integrity verification is done automatically at the package level. Both authenticity of the repo meta-data and packages is verified via cryptographic signatures at install or query time.
Level 3: Integrity verification is possible at the individual file/component level both at install and query time, as well as offline at a given point in future post-installation to detect changes. Both authenticity of repo meta-data and packages can be verified via cryptographic signatures, at install or query time or offline. Identity of signing entity is establish by a 3rd party such as a CA with a verifiable chain of trust.

Wouldn't it be preferable to, at peak maturity, have authenticity and integrity and non-repudiation at the level of individual code check-ins, builds, etc?

You want both imo. They are related but different things.

Yes. I see how what I said was ambiguous. I completely agree with you. But transparency in package management often whitewashes the opacity of identities and veracity of code contributions.

So we need to create accountability and transparency in both the code contributions (think gitops) and package management. Getting a Red Hat package that is signed by Red Hat seems great until you think about whether they pulled in their Rust crates with cargo (or their Python with PIP, or their JS with NPM, base container from Docker Hub,...) I want to know exactly where my code came from, and who submitted it, who they are, where they live, who they work for, and what they think about Travis Kelsey.