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