Thinking about sandboxing

[Poul-Henning Kamp]

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
offers.

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:

    $user
	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.

    $group
	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.

    $group_vsm
	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.

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

    feature::public_vsm
	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

subprocesses:
	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.