Thinking about sandboxing

[Poul-Henning Kamp]

--------
In message <54DB6EB5.7080403 at schokola.de>, Nils Goroll writes:

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

That is part of the problem I'm trying to resolve, I think my proposal
allows us to do so without too much hazzle, simply because we can
create the files after sandboxing, thereby getting the uid right
from the start.

>I think the varnishd master process (level#0) should continue to run as a
>different $master_user (root) 

The master will run with the uid it started, whatever it is.

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

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

What for ?

The increment of security is pointless IMO.

>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

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