> Date: Mon, 13 Apr 2015 19:57:12 +0000 > From: Poul-Henning Kamp <p...@phk.freebsd.dk> > To: varnish-dev@varnish-cache.org > Subject: Varnish jails, priv-sep, packaging etc. > Message-ID: <92310.1428955...@critter.freebsd.dk> > Content-Type: text/plain; charset="us-ascii" > > I have spent time over Easter thinking about the jail/priv-sep thing, > and in particular about the child process. > > (All of this applies only when varnishd is started as root.) > > Assume the worker process has been possesed. > > How can we prevent it from making the possession persistent ? > > For starters it should not be able to manipulate the compiled VCL > shlib files. > > Today we use varnish:varnish ($params) for all the privsep subprocesses > (ie: VCC/CC/DLOPEN/WORKER) > > This means that a possesed worker process in principle can replace > the compiled VCL shlib files (because permissions allow CC to write them.) > > That could be remedied by changing the ownership of the -n directory > and having the VCC/CC/DLOPEN operate out of a varnish:varnish owned > subdirectory. > > But the possesed worker could just continously scan the -n directory > and jump in when a VCL compilation was happening and corrupt the result. > This limits the opportunities somewhat, but it doesn't close the hole. > > There is also the general question of file access, I don't think it is > safe to assume that the worker should have access to anything VCC or CC > have access to. > > This argues strongly for a separate uid for the worker process. > > > The next question is the ownership of the default secret file. If people > specify one with -S it is not our problem, but the default config it is. > > The worker should certainly not have access to this file and > should absolutely not be able to write or replace it, which it can today > because the -n directory is varnish:varnish. > > > So the result I come up with is the following: > > Assume that varnishd is started as root:wheel > > Assume that we have a "varnish" group and "vadmin" and "vrun" users. > > -n directory root:varnish 755 > We cannot make it 750, because then admins > with wheel group can not get to the secret/vsm > files. > > _.secret root:wheel 440 > > _.vsm vadmin:varnish 644 > > vcl$shlib vadmin:varnish 750 > > Subprocesses VCC and CC runs as vadmin:varnish. The master process creates > a temporary compilation subdirectory under ${-n} with vadmin:varnish 750 > and once the shlib is done, moves it up to ${-n} and changes m:o:g > > Subprocesses DLOPEN and WORKER runs as vrun:varnish and therefore cannot > read the _.secret file, and cannot write or replace vcl shlib files. > > In addition: > > The -j arguments "ccgroup" is bestowed on the CC process > > The -j argument "secretgroup" overrides the primary group > from the master process for the _secret file (Allowing it > to be set for instance to "operator"). > > I have given up on using "nobody" instead of "vrun" for two reasons: > > First "nobody" is used for all sorts of stuff, and it's only a matter > of time before there is an unintended consequence of that. >
Agreed > > But more importantly, by having a specific uid for the worker process, > we give admins a way to control access to files VMODs needs, GEO-IP > databases etc. etc, and it makes it possible to isolate directories > which VMODs can create and write files to -- "nobody" would be very > inappropriate for that. > > Agreed > So is this acceptable from a packaging perspective ? > > I don't see why not. > What should we call the users ? > > The vadmin one could simply be "varnish", but what do we call the > vrun user ? I think we have to respect the historical 7-char limit > so "varnish-run" is out of reach, and "vrun" is only logical to VTLA > afficionadios like us. > vrun. There is a long history from my perspective of naming like this. It's straightforward and states the purpose in the name. > Comments, inputs, ideas ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > > ------------------------------ > > _______________________________________________ > varnish-dev mailing list > varnish-dev@varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev > > End of varnish-dev Digest, Vol 109, Issue 4 > ******************************************* >
_______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev