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

[Andrea Bolognani]

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

-- 
Andrea Bolognani / Red Hat / Virtualization