Thinking about sandboxing

[Nils Goroll]

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"
below):

* 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?

Nils