[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [PATCH] deploy docs to qemu-project.org from GitLab CI
Date: Tue, 19 Jan 2021 17:39:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

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.


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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]