Thinking about sandboxing

[Nils Goroll]

Hi,

phk and myself have continued this discussion a bit, but he had to leave, so I
am continuing here.

On 11/02/15 18:19, 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
> 
> If your master process runs as root, it can setgroups itself into $group.

On solaris, it can if it has the proc_setid priv. On linux, this should be
CAP_SETGID.

So, yes, master could setgroups() itself into $group. But then there is the
(solaris-specific) issue that we cannot avoid the SNOCD flag getting set for the
master process *1). The main consequence is that the master process cannot be
controlled/inspected (e.g. have signals delivered, proc-tools used) from
processes with the same uid/gid unless they have the proc_owner privilege.
Another consequence is that we don't get core dumps unless setuid core dumps are
enabled globally, but this is an issue anyway *2)

In short: If we can, we should avoid any uid/gid fiddling (including
setgroups()) in the master process, but I'd not consider this a blocker.

>> I suggest to have a configurable $vcc_dir [...]
> 
> What for ?

If master runs as user/group master:master and -u varnish -g varnish are used, I
don't see how master could read

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

(unless it setgroups to $group, see above).

So I suggested one directory "owned" by master any one shared for vcc/worker:


# 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

> The increment of security is pointless IMO.

Which is why I wrote "marginal".

>> 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?
> 
> See ad6bf9c0e51954cc45fee92d484e95c666d99685 and #1521

Thanks for the pointers.

Nils


*1) I still need to re-check the current code, it looks like it gets set anyway
    at the moment.

*2) see (now improved) comments in bin/varnishd/mgt/mgt_sandbox_solaris.c