Thinking about sandboxing

Poul-Henning Kamp phk at
Wed Feb 11 10:39:31 CET 2015

So inspired by #1663 and stuck in trains and meetings yesterday, I
went over the VCC/CC code and spent some times staring into the
future of sandboxing.

Just to re-iterate our overall security model:

level#0:  The privilege used to start varnishd

level#1:  The privilege to access CLI

level#2:  The privilege to access VSM (VSC/VSL)

level#3:  The privilege to send a request through the worker

It is worth putting in the record, that with the advent of
VMODs we have given up the ability to sandbox subprocesses
(VCC/CC/VCLLOAD/WORKER) into the working directory:  They need
to be able to reach out and find VMODs and God only knows what
the VMODs themselves will try to accesss.

This reduces the "unix-level" sandboxing to the question of
ownership and modes on and in the working directory plus
whatever enhanced sandboxing the particular operating system

We have traditionally used nobody:nogroup (uid:gid) for sandboxing,
but I have reached the conclusion that we should migrate to a
dedicated varnish:varnish identity.

For instance getting to the VSM (level#2) means that you need to
be able to get to the VSM file in the working directory, which again
has implications for the permissions on that directory and the path
to it.

But separating level#1 and level#2 access requires there to be
different access to the _.vsm and _.secret files, and both
privileges should ideally be group based.

After thinking about all of this for some time, this is what
I came up with:

We have the following parameters:

	The $user defaults to "varnish" (!root: $uid) and is used
	to own all files created by varnish, and to prevent other
	programs or identities from pulling the rug under varnishd.

	The $group_cli defaults to "varnish", (!root: $gid) but
	can be set to any random group, in which case it acts as
	restrictor for level#1 access for this instance of Varnish
	and can be used as restrictor for sensitive VCL and VMOD files.

	The $group defaults to "varnish", (!root: $gid) but
	can be set to any random group, in which case it acts as
	restrictor for level#2 access for each instance of Varnish.

	Platform dependent group added to the CC subprocess for
	access to C-compiler bits.  (default: empty)

	The VSM will be publically readable, defaults to false.

Suggested permissions:

-n directory: 		755 $user:$group
	_.vsm		640 $user:$group_vsm	(!feature::public_vsm)
	_.vsm		644 $user:$group_vsm	(feature::public_vsm)
	_.secret	640 $user:$group
	vcl.*.c		660 $user:$group	(temporary file)
	vcl.*.so	440 $user:$group

	VCC		$user:$group
	CC		$user:$group+$group_cc
	DLOPEN		$user:$group
	WORKER		$user:$group

Comments ?

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.

More information about the varnish-dev mailing list