sys-kernel/pentoo-sources should support verify-sig

[emdee-is]

Pentoo is a "hardened" distro, and a real basic is to verify the signature of kernel sources. kernel.org signs its releases with 79BE3E4300411886 or 38DBBDC86092693E. So pentoo-sources should support the verify-sig USE flag.

Suporting signed source files by the originator is a huge advantage of Gentoo-portage, and Pentoo would do well to highlight this,

Once that's done maybe you could open an issue upstream so that they should be using verify-sig on linux-firmware with A31B6BD72486CFD6 which is also security-critical,

[blshkv]

I guess, you are asking to implement authenticity verification, not integrity. Because portage does verify integrity by default.

Personally, I don't see big advantage as the current implementation of verify-sign is not 100% secure. Here why. The verify-sig eclass uses the following 3 URLs:

   SRC_URI="https://libvirt.org/sources/${P}.tar.xz
      verify-sig? ( https://libvirt.org/sources/${P}.tar.xz.asc )"
   BDEPEND= "verify-sig? ( sec-keys/openpgp-keys-libvirt )" (optional, will be downloaded during initial install only)

In practice, all 3 files will be downloaded from the same gentoo mirror server which you can't really trust. Yes, keys will be downloaded once only (during the first installation), but that's not a point.

As you can see, it's all about how to download the key securely. First of all, It should not be mirrored. And I don't see a way to lock it to a specific the hash key (79BE3E4300411886 or 38DBBDC86092693E) in the current implementation of verify-sig

Also see https://mgorny.pl/articles/verify-sig-by-example.html

[emdee-is]

you are asking to implement authenticity verification, not integrity

Correct.

I appreciate your scepticism, but I think it works, and if it works, it's a really big plus.

1) You the originator of libvirt (example) create the .asc file which signs the .tar.xz with your key. The .asc is the lock to a specific key - yours.

2) The sec-keys/openpgp-keys-libvirt downloads the key from you not the mirror, if you don't have the key in your/portage's keyring. You however can download and/or trust the key however you like and check the key independently of the mirror.

Look in /usr/portage/sec-keys/openpgp-keys-kernel/openpgp-keys-kernel-20201103.ebuild which contains the instructions of where to download the keys from. You're right; the keys are downloaded from kernel.org not the mirror. The mirror only tells portage where to download the keys from.

(So the kernel keys for the kernel.org part of pentoo-sources is already in Gentoo, including the 2 keys I mentioned. sec-keys/openpgp-keys-kernel can be a dependency of pentoo-sources)

3) Any discrepancy between the mirror downloaded .asc and your (libvirt's) release .asc (from say github or kernel.org) will be easy to spot.

I don't think the impersonation of keys from kernel.org has ever been a problem, and I don't think downloading the location of the keys from a mirror is a big problem as you can download and/or trust the key independently of the mirror. If this was a real problem, kernel.org would not bother to sign things in the first place...

Gentoo has put a lot of work into sec-keys (ls sec-keys/* | wc ~= 100) and I think it is unique amongst the package managers and very important for things like pentoo-sources and linux-firmware what with all of the MITM proxies. If you still have your doubts, I'd trust that Gentoo is implementing this good reasons, and as it's easy to add at least the verify-sig of the kernel.org files, I'd ask you move forward on that.

And of course if you added a sec-keys/openpgp-keys-pentoo and signed the pentoo bits so much the better. (I don't know if you need an sec-keys/* as you already have a /usr/share/pentoo/pentoo-keyring.asc but I'll leave that to you.) I'll open another issue saying I can't believe pentoo ships unsigned releases, like I did for opensnitch :-) https://github.com/pentoo/pentoo-overlay/issues/1173

[ZeroChaos-]

Does Gentoo support verify-sig on gentoo-sources? Our sources are gentoo-sources with a few small patches on top and a config file.

[emdee-is]

No - nor on linux-firmware.

I think I see the problem - you just do a inherit kernel-2

Does pentoo open upstream issues with Gentoo? If you agree with me that verify-sig would be A Good Thing, then maybe pentoo could open verify-sig issues upsteam for gentoo-sources and linux-firmware, and track that issue here,

[blshkv]

As you can see, the key was downloaded from the mirror here

So no, it doesn't really work, and integrity check is more reliable for now. A paranoid person should get a key from a key server and verify it manually. Or in person.

[emdee-is]

I share your concern about not mirroring openpgp keys, but don't think it is "key" for 2 reasons:

1) The SRC_URI in the ebuild is the kernel.org key, not the distfiles URI. If you do an emerge -fp openpgp-keys-kernel you'll see the distfiles and the kernel.org URLs with the distfiles first. It could be that standard portage voodoo is generating the distfiles URL and it's a portage bug that needs filing upstream that the standard distfiles mirror voodoo should not be applied to openpgp keys.

2) A paranoid person like you can easily filter the distfiles URLs from the output of emerge -fp sec-keys/* and download all the keys from originators, and take full advantage of verify-sig, verify-sig then does work, And it's a whole different ballgame from chasing the identity and location of all of the keys and downloading them yourself, or using unsinged software.

As an end user of a hardened system I want the kernel and the firmware verified, and will easily put up with some key caching as an open issue to be addressed. It's also just an open issue with an obvious work around with a simple emerge|sed|scurl filter, In fact, Pentoo could do exactly that in scripts/pentoo-updater.sh - emerge -fp |sed and scurl locked againsr protocol downgrades - and advertise that as a hardening feature of Pentoo - no cached openpgpg keys.

So please don't throw the important concept of verify-sig out because of a potential mirror flaw that can be easily worked around, and could be a strong feature of Pentoo.

[ZeroChaos-]

Everything should be mirrored. We already have verify-sig on for every package which Gentoo has support for. I will accept this bug as a note for improvement.

[blshkv]

It would be funny if you would say that a mirrored key can be verified by checksum

[ZeroChaos-]

"I can trust this key because I downloaded it from kernel.org" has the literal same meaning as "I can trust this pentoo iso because I downloaded it from pentoo.org", so who needs keys anyway? You either trust the process or your verify yourself. That said, I'm fine improving the process for those who trust it, that's why verify-sig is enabled by default.

[emdee-is]

@ZeroChaos what makes you think that "verify-sig is enabled by default" in either Pentoo or Gentoo? If so I'm delighted, but I see a request to have it added to Gentoo https://bugs.gentoo.org/856928. The request has not been acted on for reasons that I consider to be False, because to me a hardened profile implies defence-in-depth.

If I'm right and it is not on by default in Gentoo, can we turn it on in the hardened profile in Pentoo?

If you're right and it is on by default in Gentoo, can we turn it on in the hardened profile in Pentoo anyway to make it explicit?

Either way, as you have an account on bugs.Gentoo.org could I ask you to file 2 requests for Gentoo to support verify-sig on linux-firmware and gentoo-sources as they have signed packages and to me are security critical. (You're more likely to be using bugs.gentoo.org that I am.)

[ZeroChaos-]

verify-sig is activated on Pentoo by default, and you shouldn't be opening related bugs without checking the kinds of things. Please don't waste my time.

[blshkv]

@emdee-is the flag is enabled here https://github.com/pentoo/pentoo-overlay/blob/master/profiles/pentoo/base/make.defaults#L45 So we do try our best to use all security features available in Gentoo.

I guess there are two points from this bug report:

• verify-sig can be improved in Gentoo (like adding RESTRIC="mirror" for all sec-keys/openpgp* packages, adding VERIFY_SIG_OPENPGP_KEY_HASH)
• add verify-sig to kernel-2 eclass (it is currently used in sys-kernel/vanilla-kernel only)

Both improvements should be done by Gentoo. (ZC is the Gentoo dev btw). Feel free to open upstream bug reports.

[blshkv]

it looks like Gentoo guys know about that problem: https://bugs.gentoo.org/856928 The verify-sig USE flag is meant for developers to verify signatures when they add a new ebuild to the repo. Once the file is in the Manifest, signature verification is mostly pointless overhead.

[ZeroChaos-]

FWIW I agree, it is mostly pointless overhead, BUT. I enabled it by default anyway because I accept the cost to avoid the very small chance of vulnerability

[blshkv]

https://bugs.gentoo.org/864262

[emdee-is]

@ZeroChaos I did look for it before I commented with

find /var/db/repos/pentoo/profiles/pentoo/hardened/ -type f -exec grep 'verify-sig' {} \; -print

but missed it being set in base. @blshkv thanks for pointing out that it is in profiles/pentoo/base/make.defaults . Note that the comment is incidental to the issue that I opened which is it's "a real basic is to verify the signature of kernel sources. "

Also, practically speaking, I don't think the following is necessarily true:

"I can trust this key because I downloaded it from kernel.org" has the literal same meaning as "I can trust this pentoo iso because I downloaded it from pentoo.org", so who needs keys anyway?

for 2 practical reasons: 1) a MITM/BadOnion adversary might hesitate to screw with keys because of a much higher risk of detection, but happily screw with ISOs (This has been seen in the wild with BadOnions on Tor).

2) I can write a simple script that iterates over all of the keys of a keychain/directory and downloads the keys from different trusted sources and compares them. It's relatively easy to try to spot a bad key, compared with an unsigned ISO that can be downloaded from only one place.

@blshkv I pointed to that issue https://bugs.gentoo.org/856928 and this is why I disagree with the reply and their inaction (a simple change that Pentoo did do in the base profile).

@ZeroChaos- Either way, as you have an account on bugs.Gentoo.org could I ask you to file 2 requests for Gentoo to support verify-sig on linux-firmware and gentoo-sources as they have signed packages and keys available and are security critical. And then leave this issue open in Pentoo until Gentoo is supporting verify-sig on those packages to track the progress...

[ZeroChaos-]

I do not exist to file bugs for you.

[emdee-is]

@blshkv in https://bugs.gentoo.org/864262 to "getting downloaded from the same (untrusted) location" you can add "with the same untrustworthy downloader." because in Pentoo, unless you set FETCHCOMMAND in make.conf to something better, the Gentoo default wget is susceptible to insecure prootocol downgrading AND may be launched with --no-check certificate (see portage/_emirrordist/FetchTask.py)

So you need a FETCHCOMMAND with "curl --tlsv1.2 --proto-default https --proto =https " ...

But then the fun begins - try putting a FETCHOMMAND that uses curl and then rename /usr/bin/wget to something else and you may see what I see - Pentoo ignores you and tries to uses insecure wget anyway.

portage.exception.CommandNotFound: wget
 * Fetch failed for 'app-admin/

[emdee-is]

@ZeroChaos- Nasty - @blshkv said you are the Gentoo dev and I see you have open issues there, so obviously it would have been more efficient for you to track them.

We've used Pentoo for 5 years and have dozens of fixes and security improvements, so I can easily go back to not existing to file bugs in Pentoo for you either. Like everyone else it seems...

[blshkv]

default wget is susceptible to insecure prootocol downgrading AND may be launched with --no-check certificate (see portage/_emirrordist/FetchTask.py)

you need to come up with a test case and harden each of it. If you worry that Gentoo can run wget without cert check, then they can ignore your FETCHCOMMAND command too...

[emdee-is]

There are 2 separate issues here, one easy and one harder:

1) Unless you use FETCHCOMMAND portage is using wget which can have it's https: downgraded to insecure protocols, opening it to MITM attacks. The fix is to in make.conf or equivalent add (untested)

FETCHCOMMAND='curl --tlsv1.2 --proto-default https --proto =https --retry 1 --connect-timeout 10 --output "\${DISTDIR}/\${FILE}" "\${URI}"'
FETCHCOMMAND_HTTP='curl --retry 1 --connect-timeout 10 --output "\${DISTDIR}/\${FILE}" "\${URI}"'
FETCHCOMMAND_HTTPS='curl --tlsv1.2 --proto-default https --proto =https --retry 1 --connect-timeout 10 --output "\${DISTDIR}/\${FILE}" "\${URI}"'
RESUMECOMMAND='curl --tlsv1.2 --proto-default https --proto =https -C - --retry 1 --connect-timeout 10 --output "\${DISTDIR}/\${FILE}" "\${URI}"'
RESUMECOMMAND_HTTP='curl -C - --retry 1 --connect-timeout 10 --output "\${DISTDIR}/\${FILE}" "\${URI}"'
RESUMECOMMAND_HTTPS='curl --tlsv1.2 --proto-default https --proto =https -C - --retry 1 --connect-timeout 10 --output "\${DISTDIR}/\${FILE}" "\${URI}"'

That's a good hardening that can go into Pentoo no matter what.

2) Even with this I see emerge using wget, but I can't find where it gets wget from - maybe it's in FetchTask.py but it's hard to nail down because they're using multiprocessing. If emerge is ignoring FETCHCOMMAND then thats a Gentoo bug. Hardwiring wget --no-check-certificate in FetchTask.py is an abomination anyway and deserves a Gentoo bug report - it is clearly used in FetchTask,_fetch_uri without consulting FETCHCOMMAND.

So if you can consider adding the FETCHCOMMAND to a make.conf equivalent in Pentoo, that's a good start.

[blshkv]

I don't see why would wget be less secure than curl. They both negotiate with server and they both can start with tls v1.2. I can also rewrite your curl by adding --insecure and all these extra commands will be useless.

[emdee-is]

wget is less secure than curl with --proto =https The key is the = sign.

If I recall correctly, a bare wget can be made to renegotiate from https: to http: - they've seen that in the wild with BadOnions. And the Gentoo default is a bare wget, not a wget that requires tls v1.2.

So wget or curl, I think Pentoo should explicitly set FETCHCOMMAND* that requires tls v1.2 and I think curl does something better with --proto =https.