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