Varnish jails, priv-sep, packaging etc.

Rogier 'DocWilco' Mulhuijzen varnish at
Wed Apr 15 02:13:21 CEST 2015

On Mon, Apr 13, 2015 at 12:58 PM Poul-Henning Kamp phk at
<> wrote:

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.
Yup, that is indeed scary.

This argues strongly for a separate uid for the worker process.
Totally agreed.

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.
Oh cripes, I hadn’t thought of that at all.

        -n directory    root:varnish 755
>                         We cannot make it 750, because then admins
>                         with wheel group can not get to the secret/vsm
> files.
There’s a case to be made for adding those admins to the varnish group, but
I don’t think it’s a big deal, as long as we nail down things within the

On the other hand, we could move the secret out of the directory, and use
-n + _secret instead of -n + /_secret.

        _.secret        root:wheel 440
We write this before dropping privs, and don’t need to read it at all,

        _.vsm           vadmin:varnish 644
While we’re on the subject of security, I don’t think _.vsm should be world
readable. There can be a ton of very valuable information in the VSM, like
Cookie headers. Most of your email talks about the worker getting
compromised, but you mentioned nobody. And there are possibly other
processes running that are exposed to the outside world. Either because
they talk to the network, or they are exposed through the world through

Requiring users to be part of the varnish group to be able to use VSM
consuming utilities isn’t a stretch of the imagination.

And if we do that, making the directory 750 makes a little more sense too,
since they already need to be in the group to do much useful things with

What should we call the users ?
insert 2 hard things in software joke here

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.
I like using varnish for the vadmin part. Less change from a
packaging/sysadmin perspective.

As for vrun, vworker comes to mind. Or maybe vunpriv

But I suck at naming, so I hope someone has brilliant ideas.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the varnish-dev mailing list