Secure Install Process (Cryptographic Authenticity)

[maltfield]

Requirements

• Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• Did you check to see if this issue already exists?
• Is this only a feature request? Do not put multiple feature requests in one issue.
• Is this a UI / front end issue? Use the lemmy-ui repo.

Is your proposal related to a problem?

Problem: Currently there are supply-chain security vulnerabilities in the existing install process.

Here's a great list of historically relevant cases where supply-chain vulnerabilities have compromised other open-source projects:

• https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises

Describe the solution you'd like.

The Installation process of Lemmy should be such that all software (Lemmy and its dependencies) that are downloaded from the Internet are cryptographically verified for both authenticity and integrity.

Note on hashes: Many people erroneously think that cryptographic hashes provide authenticity, but cryptographic hashes do not provide authenticity -- they provide integrity. Integrity checks are useful to detect corrupted data on-download; it does not protect you from maliciously altered data unless those hashes are cryptographically signed with a key whose private key isn't stored on the publishing infrastructure.

The solution to this issue should involve signing of releases using a small set of pinned public keys. It is not acceptable to use a massive root store (apple, mozilla, etc), due to historic and existing vulnerabilities with X.509 root stores.

Good Examples

Apt is a great example of a system where all software that's downloaded through apt-get is cryptographically verified for authenticity and integrity using PGP.

Tuf is another great example of how systems should be designed for secure download to avoid supply-chain vulnerabilities

• https://theupdateframework.io/

Bad Examples

Downloading files over wget with https is not safe.

https does not utilize pinned public keys, and the private keys live hot on the same server. It relies on the X.509 root store, which historically has had numerous compromised keys in it.

Moreover, https provides zero protection from Publishing Infrastructure compromise. One particularly nasty example of this was what happened to the official Monero wallet. https provides zero protection from Publishing Infrastructure compromise because the signing happens on the same server -- but cryptographically signed releases (where the private key doesn't live hot on the server) does provide protection from Publishing Infrastructure compromise.

Monero is a good case study because they actually were cryptographically signing their releases with PGP. Because of this, their users had a means to detect that the software they downloaded was malicious. It was reported to the developers, and the issue was promptly resolved. But without signing releases (as is currently the case with Lemmy), a user has no way to know if the software they downloaded is [a] authentic or [b] maliciously modified.

By default, Docker does not provide cryptographic authenticity checks at all, and it doesn't use pinned certificates, so the docker-compose command (which itself will docker pull) is not safe:

wget https://raw.githubusercontent.com/LemmyNet/lemmy/main/docker/docker-compose.yml
...
docker-compose up -d

Of course, the install process of "rustup" is horribly insecure

# don't ever do this
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

I'm unsure if installing software with cargo includes cryptographic authenticity and integrity verification of all downloaded software (beyond the shortcomings of https) by default or not

• End-to-end integrity of crates in registries rust-lang/cargo#4768

Describe alternatives you've considered.

Currently it does not appear possible to download Lemmy securely.

Additional context

No response

[dessalines]

You can build lemmy from source rather than via docker, if you want it to be cryptographically secure.

[maltfield]

And how does one securely obtain the source code? Are you signing your source tarballs?

This is a very disappointing response. Most privacy/security-oriented projects sign their releases with PGP. I expected better from Lemmy :(

[dessalines]

Is git clone from multiple sources not secure? I had no idea.

[maltfield]

@dessalines correct, there are multiple vectors of attack that your admins/users are vulnerable-to if you don't sign your releases or your source code using an offline key (eg publishing infrastructure compromise)

For an incomplete list of historical supply chain incidents that have affected other open-source projects in the past, see:

• https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises

Consider, for example, monero's release infrastructure comprimise in 2019. Fortunately, because monero was signing their releases, some users were able to very quickly discover the attack. But with Lemmy, admins doing an upgrade could receive a maliciously-modified copy of the lemmy software and (currently) they have no way to verify the authenticity of the lemmy software after downloading it. Due to this vulnerability, it's quite reasonable to suspect that some admins are already running compromised lemmy servers due to this existing supply chain vulnerability.

Please reconsider signing your releases to fix this security vulnerability in Lemmy.

[Nutomic]

Do you know any resources which explain how to setup such authentication for a release process? Specifically for Docker containers, and preferably in a way that doesnt require much extra effort for devs and admins.

[maltfield]

@Nutomic for security, it's best to keep your release signing private key offline. As soon as you put your private key exposed on some server, you open up yourself to vulnerabilities again.

There's some complex ways to do n/m multisig from devs with an HSM that's plugged-into a CI server, but it's probably overkill.

But I wouldn't let perfect be the enemy of the good here. Just have a process where one dedicated dev verifies the release is authentic, creates a detached signature file of the release (or detached signature of a SHA256SUM digest file) locally using their personal PGP key (recommend RSA 4096-bit), and uploads the signature file to the GitHub release page. That's what most orgs do.

For best-practices, see also:

1. https://infra.apache.org/release-signing
2. https://docs.opendev.org/opendev/system-config/latest/signing.html
3. https://wiki.debian.org/Subkeys
4. https://riseup.net/en/security/message-security/openpgp/best-practices

[maltfield]

btw, docker has a concept of release signing called "Docker Content Trust", but it's pretty horribly broken, has been for a long time, and--imho--probably should be avoided as a secure way to obtain software from non-private docker registries.

• Fix DCT Security Theater (TOFU) docker/cli#2752