Portage Security

From Gentoo Wiki
Jump to: navigation, search

This page aims to answer the question "How can I dispel doubts regarding the security of the Gentoo ebuild repository on a system?" That is, to ensure each file under /var/db/repos/gentoo is entirely composed of code written by or reviewed by Gentoo developers.

This question is answered differently whether the webrsync, rsync, git-mirror, or canonical git repositories directly method is used.

Note
systemd-resolved from systemd before version 239 causes gpg keyserver refresh failures https://github.com/systemd/systemd/issues/8164

webrsync

Whenever emerge-webrsync is run with the appropriate settings, the downloaded tarball is always checked against Gentoo release keys which are provided by app-crypt/gentoo-keys.

The only caveat is that this method doesn't do further checking after having unpacked the tarball. So, if the Gentoo repository was compromised before the webrsync, it's possible that it's still compromised. If the state of the Gentoo repository is in question, wipe it out before doing emerge-webrsync.

Configuration

The public key used to verify signatures is provided by app-crypt/gentoo-keys. In the case it's not updated in a timely manner, manually update those keys with:

root #gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --refresh-keys

Dispelling doubt

Seeing "Checking signature..." should be enough to dispel doubts. Also, reading the contents of `/usr/bin/emerge-webrsync` which is small enough to be easily audited.

Hardcore users can arrange a man-in-the-middle attack and check that verification fails.

Verifying trust

  1. That the Gentoo's release keys haven't been compromised.
  2. That the content on the file that SRC_URI point to in app-crypt/gentoo-keys is actually the Gentoo release keys
  3. Everything that is needed to trust in the "canonical git repos" method.

rsync

Portage 2.3.21+ supports recursive signed manifests checking. Project:Portage/Repository Verification explains how it works.

Configuration

  1. Ensure that portage has the rsync-verify flag
  2. Make sure that emerge --sync emits "Using keys from ..." and "Valid OpenPGP signature found"
  3. Never miss errors during --sync

Dispelling doubt

Simulate malicious injection:

  1. Change an ebuild
  2. Run gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc /var/db/repos/gentoo
  3. A manifest mismatch error should result
  4. Go a step further and update the manifest with ebuild foobar-1.2.3.ebuild manifest
  5. Run gemato verify -K /usr/share/openpgp-keys/gentoo-release.asc /var/db/repos/gentoo
  6. A mismatch error will occur

Verifying trust

Same thing as with webrsync. With repository verification, the integrity of rsync mirrors are no longer an issue. So, it is not less secure than webrsync.

git-mirror repositories

The gentoo git mirror is a git repo that delivers the equivalent of the rsync method, that is, the content of the canonical git repository but with DTD, GLSA, news, and XML schema information attached and an up to date portage cache generated.

Every commit is signed by either the developer or the "repomirrorci@gentoo.org" PGP key. So, integrity is ensured through the recent sync-git-verify-commit-signature repository option.

Configuration

  1. Install app-crypt/openpgp-keys-gentoo-release.
  2. Add gentoo-mirror repo to your repos.conf
  3. In repos.conf, set sync-type to git and enable the sync-git-verify-commit-signature option

Dispelling doubt

  1. Make a local clone of the mirror
  2. Set the sync-uri to the local clone
  3. Add a commit on top of it
  4. emerge --sync should complain

Verifying trust

  1. The integrity of the "repomirrorci@gentoo.org" PGP key.
  2. The CI server isn't compromised (which would compromise the key).
  3. Everything that is needed to trust in the "canonical git repos" method.

canonical git repositories

All methods above take their content from the same source: The canonical Gentoo repository. Every commit in this repository is required so be signed by developers using PGP keys listed in Gentoo's LDAP. Those keys are listed in the Current Gentoo developers page.

Why isn't this method preferred? Because this repo doesn't contain everything it needs to be fully functional. It needs to be augmented with data repos and a portage cache needs to be regenerated at each update (which can take a little while).

Despite this method being more hassle, it has the advantage of having a different trust model: trusting release keys and infra is no longer required for portage tree updates. Directly trusting developers and the strength of their PGP web of trust.

Configuration

Follow instructions from Gentoo ebuild tree from scratch.

Dispelling doubt

Because this method requires self-configuration of the verification processes, there shouldn't be much doubt left once complete.

Verifying trust

  1. That the web of trust of Gentoo developers is strong.
  2. That Gentoo developers have good practices regarding the security of their private PGP key.

The great thing about this trust model is that it doesn't rely on infrastructure integrity. Sure, a developer's key can be compromised but it's something that can easily be spotted (especially by the compromised developer. "hey! that commit isn't mine!") and integrity and trust is easy to bring back (review all recent commits by this developer and remove malicious ones). There is no single point of failure.

See also