Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5927

Re: GPG verification of apt packages

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

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
>
>

Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

GPG verification of apt packages Ramin Doe <ramindough@gmail.com> - 2021-01-27 19:30 +0100
  Re: GPG verification of apt packages Jonathan Hutchins <hutchins@tarcanfel.org> - 2021-01-27 20:20 +0100
  Re: GPG verification of apt packages Noah Meyerhans <noahm@debian.org> - 2021-01-28 06:40 +0100
    Re: GPG verification of apt packages Ramin Doe <ramindough@gmail.com> - 2021-01-28 19:10 +0100
      Re: GPG verification of apt packages Clément Hermann <nodens@debian.org> - 2021-01-28 20:50 +0100
      Re: GPG verification of apt packages Noah Meyerhans <noahm@debian.org> - 2021-01-28 21:00 +0100
        Re: GPG verification of apt packages Ramin Doe <ramindough@gmail.com> - 2021-02-01 20:00 +0100
        Re: GPG verification of apt packages Ramin Doe <ramindough@gmail.com> - 2021-02-03 22:00 +0100
          Re: GPG verification of apt packages Clément Hermann <nodens@nodens.org> - 2021-02-04 10:10 +0100

csiph-web