Re: [PATCH] deploy docs to qemu-project.org from GitLab CI

[Paolo Bonzini <pbonzini@redhat.com>]

On 19/01/21 15:56, Stefan Hajnoczi wrote:
> Hmm...the UNIX account on qemu.org is locked down to some extent but I
> don't feel comfortable with a GitLab CI job sshing into qemu.org.

As you say, the qemu-deploy account on qemu.org is limited to writing to 
/var/www/qemu-project.org.  Its own home directory is also limited with 
"chattr +i".

The same CI runners are already using the qemu-deploy user to deploy the 
website itself.  (To state the obvious, you can only do this if you can 
push to the qemu-project GitLab organization.  Regular users can 
configure their fork to deploy to a different server using a different 
ssh private key, but their CI jobs won't touch qemu-project.org).

There are other ways to do defense in depth.

We could use https://www.hashicorp.com/cloud-platform for the ssh 
private key.  Right now the ssh private key (which of course only grants 
access to the qemu-deploy user) is accessible to everyone with 
administrator access to the QEMU GitLab project; a Vault instance could 
have more limited access.

With respect to the ssh private key, however, a bigger risk factor is 
that a botched (even if not malicious) patch can reach the QEMU or 
qemu-web git repositories, causing the private key to appear in public 
CI logs.  To mitigate this we could set up a restricted bash for the 
qemu-deploy user on qemu.org.  It would require small changes to 
gitlab-ci.yml to avoid the "cd" command, as well as configuring a 
restricted PATH via ~/.ssh/environment, but overall it would be easy. 
It would also protect against a malicious actor sneaking in a patch to 
gitlab-ci.yml that makes it do bad things.

Neither of these has to be done now.  The current way to do things is 
more or less what GitLab recommends so, security-wise, it's not entirely 
broken.

> ssh access aside, we are publishing HTML from a shared CI runner to
> qemu.org. Effectively we are allowing an untrusted machine to publish
> HTML/JS/CSS on qemu.org. It could steal HTTP Cookies or do other
> malicious things.

Note that we don't use cookies on www.qemu.org and don't have a CORS 
policy either.  Only wiki.qemu.org uses cookies.

Paolo

> That is less of a problem when there is a dedicated
> subdomain so that the Same Origin policy can provide isolation. Maybe
> there are more recent web security mechanisms that allow us to define a
> policy so browsers do not treat qemu.org/docs/* the same as other
> qemu.org pages?
> 
> (This wasn't a problem before since the container was running on a
> dedicated instance under our control.)