Christoph Liebender <christoph@liebender.dev> wrote:
> Hi ports@,
> 
> this patch adds unveil(2) sandboxing to www/anubis. I think it is 
> probably a good idea in this case, as anubis is intended to "take the 
> beating" in a reverse-proxy setup. Because of this and the fact that the 
> daemon runs as the www user (which is not a daemon user), the things 
> that it can do should be restricted.
> 
> Initially, I suggested both pledge(2) and unveil(2), but stu@ argued 
> that pledge would be too much to support reliably. This is why this 
> patch only adds calls to unveil. The call site is before the daemon 
> starts listening. So any kind of configuration parsing is already done. 
> If I understand correctly, the only things then required are, depending 
> on configuration:
> 
> - /etc/{resolv.conf, hosts, ssl/{cert.pem, openssl.cnf}} with read
>    permissions, when TARGET is set to a hostname
> - read-write on TARGET if it points is a unix socket
> - create on BIND if BIND_NETWORK is unix (same for METRICS_BIND)
> 
> comments, testers, ok?

not a user, just a drive-by comment.

Usually we try to keep these kind of changes local to the ports tree
because upstream may not care and then it could break easily.  However,
in golang this is a bit weird to do.  So, you already have Unveil in
golang.org/x/sys, which is a "indirect" dependency of anubis, but
relying on it could break if future release stops depending on it.  On
the other hand, i don't think we have a way to add a dependency to an
existing go project for the build.

in this regard, the go ecosystem is pretty annoying!

second thing, the usage pattern of unveil is thought to be along the
lines of

	if (unveil(path, perm) == -1)
		err(1, "unveil");

and your unveil binding is lacking the error checking.  I think you
should bubble up the errors returned by unveil(2) and call log.Fatal if
they fail, as upstream already does for other failing points.


just my two cents, not using anubis (yet?) so can't really test.


Cheers,
Omar Polo