Auditing installed Trisquel 9 against an install CD

10 réponses [Dernière contribution]
jfw01
Hors ligne
A rejoint: 02/01/2022

Hello all,

I had a rough upgrade to Trisquel9 on a minifree X200, following these procedures, some of which involve breaking the network security:

https://trisquel.info/en/forum/repository-does-not-have-release-file#comment-163030
https://trisquel.info/en/forum/repository-does-not-have-release-file#comment-163037

I have now reversed the http connections, and can software update.

How do I persuade apt (ideally booted from the burnt iso) to audit the machine against either the repository or, ideally, the trisquel_9.0.1_amd64.iso install media, so I know that I have not corrupted the machine by routing around the security?

(During the regrade, I received notice of changed configuration files, so it seems that something like this is sometimes done. I am aware that .deb files depend on md5 hashes, which may be spoofable.)

jxself
Hors ligne
A rejoint: 09/13/2010

Changing HTTPS to HTTP didn't actually route around the security. The security provided by the package manager relies on GPG signatures, not on the use of HTTPS. Even in the worst possible case scenario where you had actually downloaded something that had been modified while going over the wire to you via HTTP, the package manager would have detected this because it would have failed signature validation.

Until we have sufficiently large quantum computers that can factor RSA using Shor's algorithm then GPG signatures remain safe.
https://en.wikipedia.org/wiki/Shor%27s_algorithm

lanun
Hors ligne
A rejoint: 04/01/2021

> sufficiently large quantum computers that can factor RSA using Shor's algorithm

Spooky.

https://en.wikipedia.org/wiki/Post-quantum_cryptography

Huzzah!

jfw01
Hors ligne
A rejoint: 02/01/2022

Ok, thanks.

I will probably want to boot the live-cd and run some command-lines to understand cryptography the signatures depend on, and to verify some of them by hand. Could you point me toward anywhere that these mechanics are published?

jxself
Hors ligne
A rejoint: 09/13/2010

Check out man apt-secure - It has the details.

You would want to research the SHA-2 cryptographic hash function (SHA-256) as well as GnuPG as well as RSA, which is what Trisquel keys use. Run "apt-key list" for the list of GnuPG keys that are trusted by your system.

But I will write up something anyway.

To turn that into a concrete example: Say that you tell you tell the package manager to download coreutils (just to point to a random package) and so let's say it grabs:
https://archive.trisquel.org/trisquel/pool/main/c/coreutils/coreutils_8.30-3ubuntu2_amd64.deb

Of course, it may grab it from elsewhere depending on which mirror you're using in /etc/apt/sources.list.

How do you know that this file is is any good because there's no GnuPG signature for the .deb? Well, first:
sha256sum coreutils_8.30-3ubuntu2_amd64.deb
99aa50af84de1737735f2f51e570d60f5842aa1d4a3129527906e7ffda368853 coreutils_8.30-3ubuntu2_amd64.deb

OK great but that doesn't actually answer the question. So continue on:

wget https://archive.trisquel.org/trisquel/dists/nabia/main/binary-amd64/Packages
You will then find that hash in there. But that still doesn't answer that question because that file isn't in GnuPG signed either. It could also have been modified by Mallory!

So: sha256sum Packages
0e7ceadea1ed0d9142183870e8e57f64002bebc4197394690d48d296db09d8f6 Packages

And then:
wget https://archive.trisquel.org/trisquel/dists/nabia/Release
wget https://archive.trisquel.org/trisquel/dists/nabia/Release.gpg

And you will see that the Release file indicates that the hash is supposed to be 0e7ceadea1ed0d9142183870e8e57f64002bebc4197394690d48d296db09d8f6 and the Release file is GnuPG signed so verify it:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --verify Release.gpg Release

The /etc/apt/trusted.gpg came from the keyring location indicated by running apt key list.

And you should see:
gpg: Good signature from "Trisquel GNU/Linux <name at domain>" [unknown]

This is the process the package manager goes through.

So even if your package manager did somehow manage to download some version that had been modified as it was being sent over the wire it is computationally infeasible to both change it *and* keep the same SHA-256 hash at the same time. So the change in hash will be found and then the computer will know that it's not the correct one because it doesn't match the one on the list. And, the computer can know that list of hashes is correct because the Release file is GnuPG signed. So that's where the real security lays at: That GPG signature.

Even if the server hosting the repository was itself compromised and malicious debs were installed along with adjusting the hashes in the Packages and the Release files so that they match with the malicious ones, Mallory doesn't have the private Trisquel key that's used to sign the Release file, so the file would then fail GPG signature validation.

So either way it gets detected, and that GPG signature is what you're *really* relying on; not the use of HTTPS. GnuPG was designed with the model that signatures and even the public keys can be sent over any medium, even unencrypted and insecure mediums without compromising the security model in any way. Go read up on GnuPG and RSA and public key cryptography to learn more. Public key cryptography is all based on math that's very easy to do in one direction but very hard to do in the other. At least, until we have sufficiently large quantum computers that can factor RSA using Shor's algorithm https://en.wikipedia.org/wiki/Shor%27s_algorithm. At that point this whole thing falls apart and we'll need something different. Fortunately, efforts to address that are already underway: https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization

So if you tell the package manager to install something and the operation is successful in the end without the package manager complaining, then you know that all of the validation occurred successfully.

jfw01
Hors ligne
A rejoint: 02/01/2022

Thanks. So that gets me grounds for trusting a deb that's available online.

The other half is, given that I'm running the live-cd, comparing the trustworthy debs with the installed machine, mounted as a disk.

jxself
Hors ligne
A rejoint: 09/13/2010

"Thanks. So that gets me grounds for trusting a deb that's available online."

And also on your computer too, since it would have gone through that validation process at the time.

You can repeat that process yourself to compare. Doing that comparison against the packages on the ISO may not work though since some of them may have been updated after your installation so if you run into differences that may be why. But either way; go for it.

And, of course, this only validates that the .deb file itself is correct. It doesn't mean that the files on the computer have not been modified after they were extracted from the .deb. That's a different scenario and for that you'd want to compare the files in the .debs against the files on the computer, after having first gone through the .deb validation process.

jfw01
Hors ligne
A rejoint: 02/01/2022

"you'd want to compare the files in the .debs against the files on the computer"

Yes. Could you please recommend a procedure for this?

lanun
Hors ligne
A rejoint: 04/01/2021

You could try:

diff file1 file2

More details there:

https://www.gnu.org/software/diffutils/manual/html_node

jfw01
Hors ligne
A rejoint: 02/01/2022

Hi Lanun,

Is one of the files the deb file that I have just verified?

lanun
Hors ligne
A rejoint: 04/01/2021

No, this is about the files in the deb packages:

> "you'd want to compare the files in the .debs against the files on the computer"