[libvirt-jenkins-ci PATCH 2/5] guests: templates: Introduce a gitlab-runner RC init service template

Erik Skultety eskultet at redhat.com
Fri Apr 3 14:04:10 UTC 2020

On Fri, Apr 03, 2020 at 03:50:21PM +0200, Andrea Bolognani wrote:
> On Fri, 2020-04-03 at 09:21 +0200, Erik Skultety wrote:
> > On Tue, Mar 31, 2020 at 04:42:10PM +0200, Andrea Bolognani wrote:
> > > On Thu, 2020-03-26 at 14:33 +0100, Erik Skultety wrote:
> > > > +gitlab_runner_start()
> > > > +{
> > > > +    export USER=${user}
> > > > +    export HOME=${user_home}
> > > > +    export PATH=${PATH}:/usr/local/bin/:/usr/local/sbin/
> > > > +    if checkyesno ${rcvar}; then
> > > > +        cd ${user_home}
> > > > +    /usr/sbin/daemon -p ${pidfile} ${command} ${command_args} > /var/log/gitlab-runner.log 2>&1
> > >
> > > The version in the official documentation does this a little
> > > differently... I guess the difference is that in their case the
> > > gitlab-runner application is running as the gitlab user, wereas in
> > > ours the daemon is running as root but is instructed to execute
> > > workloads as the gitlab user. The latter seems fine, as that's what
> > > happens on Linux as well, but have you fully considered the security
> > > implications?
> >
> > It is different because I wanted a unified behaviour on Linux and FreeBSD.
> > What security implications are you talking about, can you be more specific? The
> > machines are going to run behind a NAT, the daemon executing the service should
> > be trusted by default (otherwise, engage the tin foil hat mode), the gitlab
> > user doesn't have sudo permissions (and we should not trust this user), and in
> > later patches I setup a random root password, so that only access via an SSH
> > pub key to the root account is allowed. Alternatively, we could set up another
> > service user which will have sudo (not passwordless) access and will not run
> > any services, so that root isn't accessible over the network, would consider
> > that as suitable precaution measures?
> I trust gitlab-runner in the sense that I don't expect it to contain
> intentional backdoor, but not necessarily in the sense that I expect
> it to be entirely bug-free and impossible for an attacker to abuse as
> a compromise vector. With that in mind, running it as an unprivileged
> user right off the bat is obviously strictly safer than running it as
> root and delegating the privilege dropping part to it.
> Having the same behavior for both Linux and FreeBSD is certainly
> something that we should strive for, but can we make that behavior
> the safest one of the two?
> I have tested this, though not extensively, on Linux and adding
> User=gitlab to the service file seems to be basically all that's

Did ^this actually work? I recall having some issues on Linux when I used the
User= directive and I could not get the agent pull a job from the server,
however I used it in combination with WorkingDir (or what the proper name is)
so it may have also been that one, but I definitely tried what you describe and
didn't work for me, hence the patch looks like the way it does, but now I have
to go verify your claim and if indeed it works then we can go with what you
suggest for sure. I admit that I was playing with a handful of different runner
setups, both containerized and direct executions, so a tiny mistake may have
slipped in despite the fact I was restoring the VM state from a snapshot.

> needed to make it work; for FreeBSD this setup is the one described
> in the official documentation, so I'm going to assume it's not going
> to cause any issues either.
> If we find that running gitlab-runner as an unprivileged user gets
> in the way we can certainly go back on this decision, but I would
> like to try and see if we can get the safest option to work first.

Let me try again and I'll get back to you.

Erik Skultety

More information about the libvir-list mailing list