Thinking about sandboxing

Nils Goroll slink at
Wed Feb 11 16:01:09 CET 2015

Hi phk,

I like your thoughts, but with Solaris privileges and Linux capabilities, I do
see some additional aspects to consider (I will refer to both as "privileges"

* With a privilege aware process, the ability to switch uids does not imply
  any other super cow powers.

* varnish should not require the file_chown/CAP_CHOWN (chown files owned by
  other users) nor file_chown_self (solaris "giveaway") privileges.

I think the varnishd master process (level#0) should continue to run as a
different $master_user (root) than $user (varnish) in order to tie elevated
privileges (opening reserved ports, setuid, fork, etc.) to that user and not
require them for the varnish $user [even if the user is root, least privileges
may be in effect and the master process may start with a reduced privilege set].

In this scenario...

On 11/02/15 10:39, Poul-Henning Kamp wrote:
> -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

$master_user (root) would not be able to open any of these files (or only _.vsm
for feature::public_vsm), unless it was also a member of $group and/or
$group_vsm. I don't want my root user to be a member of the varnish $group.

Creating them as $master_user (root) and giving them away would be an option
requiring one or the other chown privilege, which I think we can avoid:

I suggest to have a configurable $vcc_dir which defaults to sit next to the -n
directory (so by default it gets created in the same parent directory). The
master process would create the -n directory, the vcc subprocesses would create
the $vcc_dir. No chown involved. We'd end up with the following permissions:

# e.g. /tmp/varnish_name

-n directory: 		755 $master_user:$group
	_.vsm		640 $master_user:$group_vsm	(!feature::public_vsm)
	_.vsm		644 $master_user:$group_vsm	(feature::public_vsm)
	_.secret	640 $master_user:$group

# e.g. /tmp/varnish_name.vcc

$vcc_dir: 		750 $user:$group
	vcl.*.c		660 $user:$group	(temporary file)
	vcl.*.so	440 $user:$group

mode 750 of $vcc_dir would add marginal security (avoiding unprivileged users to
get to know about vcl names).

As is the case now, the WORKER subprocess would inherit the _.vsm mmapped, so it
wouldn't need write permission to the file.

On 11/02/15 10:39, Poul-Henning Kamp wrote:>     $group_cc
> 	Platform dependent group added to the CC subprocess for
> 	access to C-compiler bits.  (default: empty)

can you elaborate on this? Can you give an example what this is to be used for?
How would you "add" the group to the subprocess?


More information about the varnish-dev mailing list