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

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