Hi,
First, for the specific case of file(1), I agree that calling "rpath" is what
to do. No point to use unveil("/", "r").
On Thu, Jan 03, 2019 at 06:34:06PM -0700, Theo de Raadt wrote:
>
> You are abusing kernel resources.
>
if a userland program could be be crafted to abuse kernel resources, I
would saying that userland is able to DoS the kernel in some extents,
and it could be a problem on multi-users systems.
Just saying "you should not do that" will not prevent any user to do it
anyway.
Currently, unveil(2) has a static UNVEIL_MAX_VNODES restriction (128
vnodes allocated by proc). As, when considering a pathname, you are
holding the vnode for each compoment of the path, it could be hitted
quickly ("/a/path/to/file" is 5 vnodes).
If we want resource limitation to avoid abusing from userland,
setrlimit(2) could be used. But it is per process limitation. For
example, we could account the held vnode in RLIMIT_NOFILE. But I am
unsure it would be useful: the UNVEIL_MAX_VNODES limitation is lower
that default RLIMIT_NOFILES in `default' class (512).
And trying to resolv a global resource consumption (number of vnodes
held) at process level doesn't seems right (fork could be used to avoid
the per-process restricition).
But, is the situation with unveil(2) worst that before ? It seems to me
a user could already doing vnode comsuption with just opening as many
file descriptors it can (and fork and repeat when RLIMIT_NOFILES is
reached for the process).
Eventually, with one unveil(2) call, you could held more vnode than with
one open(2) call. So it is cheaper for attacker to use unveil(2) instead
of use open(2).
So I am unsure if the problem is really "abusing kernel resources". It
is more "you can't use naively unveil(2) on user provided list" bcause
your program has more chance to quit unexpectly (so eventually something
to clarify in unveil(2) man page ?)
As for any system-call, userland using it has to be ready to copte with
error code. And for unveil(2), with E2BIG error code in particular (per
unveil(2) man page: "The addition of path would exceed the per-process
limit for unveiled paths."). But as you can't undo unveil once called,
it should be decided before calling it, and it could be not trivial in
some cases. Failing to do it usually mean the program will die as the
usual code when using unveil(2) is:
if (unveil(path, perm) == -1)
err(EXIT_FAILURE, "unveil");
Regards.
--
Sebastien Marie
