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
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
