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

[Andrea Bolognani]

On Fri, 2020-04-03 at 16:04 +0200, Erik Skultety wrote:
> 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
-- 
Andrea Bolognani / Red Hat / Virtualization