I've recently written a paragraph on how to build Arch Linux packages on pkgbuild.com (a.k.a. soyuz):
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Remote_buil...
To perform the complete operation on soyuz, we need to forward the gpg-socket (and the SSH socket if different) to soyuz, which defeats the PGP / Web of Trust security model: for a person with root access to soyuz, the private key is only one passphrase away.
Thoughts?
As I understand it for now, the full-PGP way to package on soyuz is to only run extra-x86_64-build there.
All other operations can be run locally. The only area where I'm left in the dark is the "archrelease" step of "communitypkg": what's the equivalent on a foreign distribution?
-- Pierre Neidhardt
On April 7, 2018 8:23:08 AM GMT+02:00, Pierre Neidhardt via aur-general aur-general@archlinux.org wrote:
To perform the complete operation on soyuz, we need to forward the gpg-socket (and the SSH socket if different) to soyuz, which defeats the PGP / Web of Trust security model: for a person with root access to soyuz, the private key is only one passphrase away.
Thoughts?
Yes, truly defeats it. I explicitly do not recommend forwarding it to the build server. For not doing that, you will most likely need to download the final artifacts for signing. If I recall correctly we had a discussion on that topic with Bluewind, jelle and grazzolini and someone wanted to rephrase the section with better recommendations.
Cheers, Levente
On 04/07/2018 07:55 AM, Levente Polyak via aur-general wrote:
On April 7, 2018 8:23:08 AM GMT+02:00, Pierre Neidhardt via aur-general aur-general@archlinux.org wrote:
To perform the complete operation on soyuz, we need to forward the gpg-socket (and the SSH socket if different) to soyuz, which defeats the PGP / Web of Trust security model: for a person with root access to soyuz, the private key is only one passphrase away.
Thoughts?
Yes, truly defeats it. I explicitly do not recommend forwarding it to the build server. For not doing that, you will most likely need to download the final artifacts for signing. If I recall correctly we had a discussion on that topic with Bluewind, jelle and grazzolini and someone wanted to rephrase the section with better recommendations.
Cheers, Levente
I don't understand how it "defeats the PGP/Web of Trust model", if there is no way to get the key itself, and an attacker can only generate signatures, during a limited window of opportunity, *if* they can forge a valid request to *your* computer.
I'm not sure how even the passphrase helps, not that an attacker should be able to exploit that in said limited window of opportunity... because from what I've seen of using the gpg-agent-extra forwarding, it tries to ask your gpg-agent for a signature, and then gpg-agent itself spawns the pinentry dialog *on your computer*.
The only vulnerability I could see is if you have no passphrase (gpg-agent-extra IMHO should be smart enough to still ask yes/no for remote access) or you type in your password in a situation where it is the attacker's request, not your own. (But if you don't remember asking for it, why do you type your passphrase in? Or alternatively, why is failure to end up with a signature for what you wanted, not itself a red flag?) But I think the main issue with gpg forwarding was supposed to be losing your key to attacks which are not necessarily simultaneous with your SSH session...
If you're really afraid of someone running as either your user, or some user with the power to hijack your SSH session, while you're trying to sign something, then they could just switch out your built files anyway. There's literally no solution there, except to build everything on your machine and not use soyuz at all. "clave" won't help either, because it's got the same fundamental problem of not actually being your trusted machine from beginning to end.
On 08.04.2018 05:01, Eli Schwartz via aur-general wrote:
If you're really afraid of someone running as either your user, or some user with the power to hijack your SSH session, while you're trying to sign something, then they could just switch out your built files anyway. There's literally no solution there, except to build everything on your machine and not use soyuz at all. "clave" won't help either, because it's got the same fundamental problem of not actually being your trusted machine from beginning to end.
Yes, the built files may not be trustworthy if an attacker is present, but the potential scope of this is limited to our package files.
The problem with agent forwarding is that people generally configure their agent to cache passwords so they don't have to unlock their keys all the time. With that in mind, an attacker can just request that the agent signs something after the package has been signed and there won't be any dialog popping up. That includes trust signatures on the attacker's key or just messages to prove that they are someone else.
Also people might have more than one key in their agent. If you have gpg and ssh keys in there, the attacker can just connect to other machines by using your forwarded agent's ssh key. Also, again there probably won't be a prompt since the password is usually cached.
Florian
What's the best practice to disable password caching? Set the timeout to zero?
Does anyone know if it's possible to have have a zero-timeout when on soyuz while having another timeout time locally?
On Sun, Apr 08, 2018 at 05:58:11PM +0530, Pierre Neidhardt via aur-general wrote:
What's the best practice to disable password caching? Set the timeout to zero?
Does anyone know if it's possible to have have a zero-timeout when on soyuz while having another timeout time locally?
Use the `ignore-cache-for-signing` option in gpg-agent. Unsure if you can enable this only for connections to soyuz.
Use the `ignore-cache-for-signing` option in gpg-agent. Unsure if you can enable this only for connections to soyuz.
But that's only for signing, so that won't do if I have subkeys used for other purposes under the same master key, right?
-- Pierre Neidhardt
On Sun, Apr 08, 2018 at 06:09:27PM +0530, Pierre Neidhardt wrote:
Use the `ignore-cache-for-signing` option in gpg-agent. Unsure if you can enable this only for connections to soyuz.
But that's only for signing, so that won't do if I have subkeys used for other purposes under the same master key, right?
I realized that mistake shortly after. What i have done now is to launch a second gpg-agent that only provides an -extra socket with no caching what so ever.
Morten Linderud foxboron@archlinux.org writes:
What i have done now is to launch a second gpg-agent that only provides an -extra socket with no caching what so ever.
I thought of something along those lines. Can you detail the commands so that we can put that on the wiki?
-- Pierre Neidhardt
On Sun, Apr 08, 2018 at 07:09:06PM +0530, Pierre Neidhardt wrote:
Morten Linderud foxboron@archlinux.org writes:
What i have done now is to launch a second gpg-agent that only provides an -extra socket with no caching what so ever.
I thought of something along those lines. Can you detail the commands so that we can put that on the wiki?
Symlink gpg.conf and private-keys-v1.d into a new gnupg directory. Then just create a gpg-agent.conf along the lines of:
extra-socket /home/fox/.gnupg-extra/S.gpg-agent.extra default-cache-ttl 0 max-cache-ttl 0 pinentry-program /usr/bin/pinentry-gtk-2
Then you just launch gpg-agent with the homedir set: gpg-agent --homedir .gnupg-extra --daemon
Fix you ssh config to point at the new .extra socket. I'm honestly unsure why gpg-agent can't be launched into the same homedir twice. But I'm way too lazy to dig further into gnupg.
On 04/08/2018 07:49 AM, Florian Pritz via aur-general wrote:
On 08.04.2018 05:01, Eli Schwartz via aur-general wrote:
If you're really afraid of someone running as either your user, or some user with the power to hijack your SSH session, while you're trying to sign something, then they could just switch out your built files anyway. There's literally no solution there, except to build everything on your machine and not use soyuz at all. "clave" won't help either, because it's got the same fundamental problem of not actually being your trusted machine from beginning to end.
Yes, the built files may not be trustworthy if an attacker is present, but the potential scope of this is limited to our package files.
The problem with agent forwarding is that people generally configure their agent to cache passwords so they don't have to unlock their keys all the time. With that in mind, an attacker can just request that the agent signs something after the package has been signed and there won't be any dialog popping up. That includes trust signatures on the attacker's key or just messages to prove that they are someone else.
Also people might have more than one key in their agent. If you have gpg and ssh keys in there, the attacker can just connect to other machines by using your forwarded agent's ssh key. Also, again there probably won't be a prompt since the password is usually cached.
Right, like I said/implied the problem was ill-defined. It's a configuration issue, not a conceptual problem with gpg forwarding being fundamentally a violation of PGP trust.
On 04/08/2018 05:51 PM, Eli Schwartz via aur-general wrote:
On 04/08/2018 07:49 AM, Florian Pritz via aur-general wrote:
On 08.04.2018 05:01, Eli Schwartz via aur-general wrote:
If you're really afraid of someone running as either your user, or some user with the power to hijack your SSH session, while you're trying to sign something, then they could just switch out your built files anyway. There's literally no solution there, except to build everything on your machine and not use soyuz at all. "clave" won't help either, because it's got the same fundamental problem of not actually being your trusted machine from beginning to end.
Yes, the built files may not be trustworthy if an attacker is present, but the potential scope of this is limited to our package files.
The problem with agent forwarding is that people generally configure their agent to cache passwords so they don't have to unlock their keys all the time. With that in mind, an attacker can just request that the agent signs something after the package has been signed and there won't be any dialog popping up. That includes trust signatures on the attacker's key or just messages to prove that they are someone else.
Also people might have more than one key in their agent. If you have gpg and ssh keys in there, the attacker can just connect to other machines by using your forwarded agent's ssh key. Also, again there probably won't be a prompt since the password is usually cached.
Right, like I said/implied the problem was ill-defined. It's a configuration issue, not a conceptual problem with gpg forwarding being fundamentally a violation of PGP trust.
With the correct configuration, sure. But even then it still allows one to sign whatever the hack they want, (mail)texts requesting something like ssh key change or whatever like any arbitrary file one could imagine and grab the signature on the remote. It could even be made semi-stealthed to ask twice for a side-artifact and if not taking a careful notice about the lack of "wrong password" messages or whatever, most people will just enter the passphrase again and assume they mistyped.
Not saying doing "harm" to a package that later gets locally signed and uploaded to the repo can't do more devastating havoc and gain access to the packagers key if installed on that very same machine... but people should also be aware it can aid to trivially get any text signed that makes f.e. some non-legitimate claims or requests look legitimate.
Security and implications of threat models is always (additionally to hard facts) a personal thing of consideration what is acceptable and what not. People should always be made fully aware of the implications of acting in certain ways with their (distro) signing/shell keys.
Speaking purely for me, my personal decision is to never build on remote machines and especially never sign anything on them. At the end, our reproducible builds efforts will (soon) help to detect such backdoored/altered packages uploaded to our tier-1 mirrors but it will not detect maliciously signed text messages or off-repo signed and exfiltrated packages that can later be used for a targeted MitM or malicious mirrors.
So yes, if you ask me I still totally don't recommend to remote sign on a shared environment no matter how its configured... but if you feel the urge to do, then do it as good as possible.
cheers, Levente
On Sat, Apr 07, 2018 at 11:53:08AM +0530, Pierre Neidhardt via aur-general wrote:
To perform the complete operation on soyuz, we need to forward the gpg-socket (and the SSH socket if different) to soyuz, which defeats the PGP / Web of Trust security model: for a person with root access to soyuz, the private key is only one passphrase away.
Which is why I have been working on clave[1]. It helps in the cases where build artefacts are large and sorta useless to download after building. But it doesn't prevent the case where a malicious root user is capable of switching the files right after build, unless you do some additional verification after generating the signing request.
Since it creates signatures with the new packet style, it won't be supported before pacman 5.1, and I plan on improving it a bit before that time.
[1]: https://github.com/Foxboron/clave
aur-general@lists.archlinux.org