Difference between revisions of "Talk:DeveloperWiki:Repo DB Signing"

From ArchWiki
Jump to: navigation, search
(Thoughts on attacks and defenses)
(Reply to Archange)
Line 5: Line 5:
 
:Can you explain what does using a VM or ephemeral containers implies or brings vs secure enclave?
 
: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. [[User:Archange|Archange]] ([[User talk:Archange|talk]]) 10:57, 16 August 2018 (UTC)
 
: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. [[User:Archange|Archange]] ([[User talk: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. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 14:27, 16 August 2018 (UTC)

Revision as of 14:27, 16 August 2018

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)