[sudo-workers] Lowering resource limits is an issue

[Todd C. Miller]

On Thu, 19 Dec 2019 00:30:36 +0200, Kimmo Suominen wrote:

> On NetBSD the new unlimit+restore causes warnings when restoring
> RLIMIT_STACK:
>
> equinoxe:~> sudo -s
> sudo: setrlimit(RLIMIT_STACK): Invalid argument
>
> Using src/limits.c from the tip of the 1.8 branch (where RLIMIT_STACK is no
> longer set to RLIM_INFINITY) causes these errors much less often than the
> code from 1.8.29, but does not eliminate them.
>
> I added output of rlim_cur and rlim_max to see if we are trying to increase
> the soft limit beyond the hard limit -- I did not see that ever being the
> case.
>
> The other reason for setrlimit(2) returning EINVAL is that the call is
> trying to lower the limit below the current usage for the resource.
>
> Thus it would appear that it is not reasonable to simply try to reduce a
> soft limit to its previous value after having increased it. Instead, one
> would also need to (somehow) ascertain that resource usage is also shrunk
> back down below the old limit first.

That seems unlikely.  If this were the case I would expect to hit
the stack limit (and crash) if sudo didn't increase it.  You could
add a call to gerusage() and compare the value of ru_isrss to the
new limit, though you'd need to convert ru_isrss to saner units.
See ruspace() in kern_resource.c for how it is computed.

> I also wonder if the compiler / linker / kernel is using any security /
> protection methods such as allocating the stack "all over the place" (to
> prevent predicting where it is in memory) and thus making it likely that
> the resource usage exceeds the previous lower limit.

It seems more likely that this is the result of a security mitigation
of some kind.  Do you see the problem more often on 32-bit systems
by any chance?

> I looked at the archives of the sudo mailing lists searching for any
> context on why we are trying to increase the resource limits to their
> maximum values, as opposed to simply dying if a limit is hit. I could not
> find anything -- any pointers?

We want to prevent the user from influencing how sudo behaves by
artifically lowering the resource limits.  The open file limit is
probably most important here as it could be used to avoid logging
if syslog(3) cannot open a socket.  However, I've also seen odd
behavior from some libraries when malloc(3) fails.

> It would seem undesirable that sudo just leaves the user with higher
> limits, overriding policies that the administrator might have set on the
> system (e.g. in login.conf(5)).

It is probably safe to just leave the stack limit as-is since the
default behavior is to kill the process.  However, that might allow
a user to set the stack size to a value where sudo can run successfully
but the sendmail process sudo invokes in some cases would crash.

The NetBSD behavior still seems like a kernel bug of some kind to
me though.

 - todd