Thinking about sandboxing (take #2)

[Poul-Henning Kamp]

--------

Ok, take 2, after I remembered a fine point about gids[1].

Varnishd can be started four different ways:

1) As plain user:	uid=user, euid=user
2) As setuid user:	uid=user, euid=varnish
	Master does:
		setuid(geteuid())
		setgid(getegid())
	and run all processes with that uid/gid and the gidset we
	are born with.

	param $user = geteuid() -- read-only
	param $group = getegid() -- read-only
	param $group_vsm = unset -- read-only
	param $group_cc = unset -- read-only

3) As plain root:	uid=root, euid=root
	We can do whatever we want, and parameters act as described
	in previous email.

	param $user = "varnish"
	param $group = "varnish"
	param $group_vsm = unset (which means "use $group")
	param $group_cc = unset (which means "don't do anything")

4) As setuid root:	uid=user, euid=root
	This is a major security hole, because varnishd executes
	argument strings, notably "param.set cc_command".

	Off the top of my head I cannot imagine a situation where
	this makes any sense, but I think we should treat it just
	like the "plain root" scenario, rather than do policy.

In the root-case, Nils proposes that we should also lower master
process privs.

We can for instance run most of the time with:
	seteuid($user)
	setegid($group)
and re-raise to:
	seteuid(root)
only while opening sockets.

This is under further consideration for side-effects (storage
files etc.)

Poul-Henning


[1] A lot of people are unaware that groups can be used to selectively
deny access to files.  If a file is 707 foo:bar, and you are member of
group bar, you cannot read it, even though everybody else in the world
can.  The fine point I overlooked is that this is why a non-root process 
cannot relinguish a group from its set.

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