Re: GPG verification of apt packages

So after doing my reading and digging around a bit, I get a vague sense of the pieces involved. I can see the various data files available on the mirror site, that *could* be used to verify that all the files we receive are what we'd expect to be getting, based on some initial data (a trusted key) that we might have on our system. But as some have mentioned, the documentation in Securing Debian Manual (https://www.debian.org/doc/manuals/securing-debian-manual/) is out of date and/or oversimplified. It's still helpful though!

So I could see how the local keys /etc/apt/trusted.gpg.d/*.gpg might be used to verify that InRelease that is downloaded from https://[mirrorsite]/debian/dists/buster/ is trustworthy. And it looks like that InRelease file contains sha256 signatures that can be used to verify the contents of various files, including Packages.gz that would be downloaded from https://[mirrorsite]/debian/dists/buster/main/binary-amd64/). In that Packages file, there are sha256 signatures for individual packages that apt would install, and those could be used to verify all the files that were downloaded by an `apt install` command before installation.

The only thing that still worries me a little bit is that I can't actually verify that any of the described verification is actually being done, or that I have imagined the process correctly. (Is there an existing corrupted mirror I can use? Is it hard to set one up? If I could force a package rejection in different ways, I'd be fully confident it was configured and functioning correctly).

I understand, of course, that all this assumes that my system hasn't been compromised already. But, yes, if I have a clean system, and non of the keys or hashes are compromised, I can see how this would work. And this would mean that I wouldn't need to do GPG verification of the packages as described in section 7.5.2 of the Manual, and the article I first posted (https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/).

It's not entirely clear to me what the CIS guideline was expecting me to do. It says:

Verify GPG keys are configured correctly for your package manager:

# apt-key list

Perhaps they want me to install apt-key, and use it to look at the gpg keys installed on my system, and then somehow verify that they aren't compromised? Does that sound like I'm understanding them correctly?

thanks for all the help!

Ramin

On Thu, Jan 28, 2021 at 11:56 AM Noah Meyerhans <noahm@debian.org> wrote:

On Thu, Jan 28, 2021 at 10:08:32AM -0800, Ramin Doe wrote:
> The signed metadata includes cryptographic checksums of the package
> contents. Thus, package contents can't be modified in storage on the
> mirror or in transit to your system without invalidating the checksum,
> and the checksums can't be updated in the repository metadata without
> invalidating the signature.
>
> This all sounds pretty promising! Thank you, Noah! Do you happen to know
> how to access this metadata? I'd love to be able to look at it and
> understand it better.

See the signed InRelease files in /var/lib/apt/lists

> Again, I'd love to see one of these release files, so I could see:
> a) what data, exactly, is being checksummed
> b) what sort of hash algorithm is involved
> In my digging around so far, I found that the .deb file contains a
> control.tar.xz file, which has some md5 checksum information, but it has
> very patchy coverage of the files in the package. I hope that's just a
> holdover from a deprecated mechanism, and is not being used nowadays.

The MD5 sums are use by the debsums program. Because md5 is weak and
because there are plenty of ways to bypass file-level checksum
validation in general, these are more useful at identifying corruption
or valid local modifications rather than system compromise.

You should read
https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html

It's a little dated, as it still mentions the use of md5 in the Release
files when we use sha256 these days, but it's good for a higher level
overview.

noah