16

What security systems and processes are in place to prevent malicious third parties from hacking/compromising the security of code in the Debian mirrors, or to verify that the packages we get are in fact the ones the maintainers think they are?

xhienne
  • 17,793
  • 2
  • 53
  • 69
emf
  • 321

1 Answers1

25

Verifying packages

The contents of the mirrors are signed using PGP keys, directly or indirectly. Starting at the "root" of a Debian distribution:

  • Release, signed with a detached signature in Release.gpg, contains the hashes (MD5, SHA1, SHA256) of all the package indices and installer hashes (InRelease now combines the two);
  • the package indices (e.g., binary-amd64) contain the hashes (MD5 and SHA256) of the packages.

The hashes and signatures are checked by tools such as apt-get using PGP keys stored on the system (managed by apt-key). So as long as the receiving system is sound, by default no package can be installed from the Debian archives if it hasn't been signed (indirectly) by the archive PGP key. Any intruders on the mirrors wouldn't be able to replace binaries if they didn't also have control of the relevant PGP key.

Controlling the mirrors

This means that compromising the archive isn't sufficient to actually compromise end-user systems; you'd also need to compromise a PGP key which those systems already trust. (A corollary of this is that adding a key to a Debian system isn't something to be taken lightly.) That addresses your first question to some extent, since the security of the archive doesn't matter quite so much. Nevertheless, the critical systems (where signing happens) are strictly monitored and supervised, and very few people have access to them.

Maintainer expectations

Ensuring that the packages are "in fact the ones the maintainers think they are" is a little more involved. This is the path taken by a package:

  • the package is prepared by a maintainer, and signed with a key in the Debian keyring (i.e. a key belonging to an uploading Debian Developer, or a Debian Maintainer, uploaded to the Debian keyring server and merged by the keyring maintenance team);
  • the signed package is uploaded to the archive, where it is verified (amongst other things, the keys used must be in the current keyring and must not have expired, the signatures must be valid, and if the package was signed by a DM, that DM must have the relevant permissions for the package);
  • any uploaded binaries are pushed to the final archive as-is (I'm simplifying a little here, but that's the effect);
  • any missing binaries are built by a buildd and signed by the buildd's PGP key, and pushed to the final archive (which knows what buildd keys are valid, and verifies files against those);
  • all these updates are eventually pushed out to the mirror network, with the appropriate index updates (which are signed as described above).

If the maintainer uploads binaries along with the package source, these are the files which end up being served (for the time being). Since uploading binaries is now optional, it's more and more common to skip them, and eventually uploaded binaries will be dropped. (This has always been the case in Ubuntu.) Whether the other binaries match the maintainer's expectations depends on the buildd network; so buildds are also critical systems, under close supervision and with little human access. Since all the artifacts are signed, it is always possible to verify the integrity of the files: first against the maintainer's key, then against the buildds' keys, and finally against the archive's key.

The original signatures aren't available on the mirrors, and any DD can upload a missing binary. However, starting with Debian 11, all new binaries in the archives come from the build dæmons; binaries uploaded by DDs are only available from unstable, experimental, or in the backports repositories. Original signatures can be retrieved from the debian-devel-changes archives.

In summary, while the current system isn't perfect, it does provide traceability for all the files you can download from the mirrors. There are a number of efforts to improve the situation: reproducible builds (which will allow independent verification of binaries' correspondence to the published source), dropping maintainer-provided binaries...

Stephen Kitt
  • 434,908
  • Admirably comprehensive, but you could also have reasonably told the poster to go away and read the documentation. :-) – Faheem Mitha May 26 '16 at 12:29
  • 3
    @FaheemMitha I hesitated, but what documentation? There's https://wiki.debian.org/SecureApt but it doesn't cover everything... Piecing it all together is quite complex, unless there's some other documentation I'm not aware of! – Stephen Kitt May 26 '16 at 12:36
  • So do the debian OS's that users run have public PGP keys pre-embedded - which are paired to the private keys on the critical systems (where signing happens) - and apt-get verifies packages using these local pre-embedded keys, because it trusts them? – the_velour_fog May 26 '16 at 12:47
  • 1
    @the_velour_fog yes, that's (nearly) right; the public keys are shipped in the debian-archive-keyring package. apt-get verifies Release files using those keys, and packages using the hashes contained in the Release and Packages files. – Stephen Kitt May 26 '16 at 12:51
  • @StephenKitt : Can I conclude that it is generally safe to install packages using apt-get if my operating system is not compromised? What would it look like if the verification fails? Thank you for the detailed explanation. – Ohumeronen Feb 13 '24 at 19:30
  • 1
    @Ohumeronen as long as you trust the repositories configured on your system, yes, it’s safe. If verification fails you get error messages to that effect, for example “Hash Sum mismatch” or “Size mismatch”. – Stephen Kitt Feb 14 '24 at 13:59
  • Thank you very much. – Ohumeronen Feb 14 '24 at 14:07