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
