DeveloperWiki talk:Repo DB Signing

Thoughts on attacks and defenses

We need to make sure that this machine is intelligent enough not to sign packages it already signed (at least, not without manual intervention), to avoid downgrade attacks. We need also to make sure we can withstand attacks from within our own infra (thinking rogue/compromised dev or tu). I was thinking that we could, instead of using a VM, use ephemeral containers for each signing. This will add some complexity to the signing software, but I think it's worth the risk. Grazzolini (talk) 10:49, 16 August 2018 (UTC)

Can you explain what does using a VM or ephemeral containers implies or brings vs secure enclave?

Also, rogue/compromised dev/tu is concerning indeed. But I think the only things we can do regarding that is automatic reproducible builds, so that in the end the only thing a dev/tu would do is update the PKGBUILD and schedule a build, everything else being triggered by that and not user controllable. Then all the trust would go into sys ops, as everyone will be able to see PKGBUILD changes and detect treachery. We can even imagine a process where PKGBUILD changes have to be approved by a given number of devs/TUs before the build, DB update and signing process is triggered. Archange (talk) 10:57, 16 August 2018 (UTC)

I think that using a VM and a security enclave brings complications between host/guest communication. Using containers is somehow easier, in this regard. Ephemeral gives less opportunities for security issues. I'm really a VM fan, but I think in this particular case, we would be better of with containers or even plain bare metal. The weakest link will be devops, and in this sense, I think that the whole machine must be fully automated using ansible and we might even perhaps have regular security checkups on it, like running rootkit detection. Or even perhaps rebuilding the machine on a regular basis. With this kind of setup, a rogue tu/dev will have limited damage opportunity. Grazzolini (talk) 14:27, 16 August 2018 (UTC)

But that’s exactly what the secure enclave is: a bare-metal, completely independent, machine. Sorry if that wasn’t clear from the start. Archange (talk) 14:34, 16 August 2018 (UTC)

Sure, I understood, but even with a security enclave, we still need another machine in front of it handling what to sign and when. This machine I don't think should be a VM. Grazzolini (talk) 14:45, 16 August 2018 (UTC)

Ah yes indeed. So the machine “scheduling” DB signing and such should be also quite secured and isolated. I agree with that, it’s an implication of my above proposal regarding TUs/devs roles in the new system that the DB machine should not be accessible to them to ensure better security. So one machine hosting the PKGBUILDs, approval system, maybe the builds, another machine grabbing the changes (either things to build or built things) and updating the DB, scheduling the signing, and then the secure signing enclave. Archange (talk) 15:03, 16 August 2018 (UTC)