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
[email protected] | 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
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
