On 12/21/21 13:19, Linus Torvalds wrote:
On Tue, Dec 21, 2021 at 10:01 AM Waiman Long <longman@xxxxxxxxxx> wrote:
Default RLIMIT_CORE to 0 will likely mitigate this vulnerability.
However, there are still some userspace impacts as existing behavior
will be modified. For instance, we may need to modify su to restore a
proper value for RLIMIT_CORE after successful authentication.
We had a "clever" idea for this that I thought people were ok with.
It's been some time since this came up, but iirc the notion was to
instead of setting the rlimit to zero (which makes it really hard to
restore afterwards, because you don't know what the restored value
would be, so you are dependent on user space doing it), we just never
reset set_dumpable() when we execve.
So any suid exec will do set_dumpable() to suid_dumpable, and exec'ing
something else does nothing at all - it stays non-dumpable (obviously
"non-dumpable" here depends on the actual value for "suid_dumpable" -
you can enable suid dump debugging manually).
And instead, we say that operations like "setsid()" that start a new
session - *those* are the ones that enable core dumping again. Or
doing things like a "ulimit(RLIMIT_CORE)" (which clearly implies "I
want core-dumps").
Those will all very naturally make "login" and friends work correctly,
while keeping core-dumps disabled for some suid situation that doesn't
explicitly set up a new context.
I think the basic problem with the traditional UNIX model of "suid
exec doesn't core dump" is that the "enter non-core-dump" is a nice
clear "your privileges changed".
But then the "exit non-core-dump" thing is an exec that *doesn't*
change privileges. That's the odd and crazy part: you just disabled
core-dumps because there was a privilege level change, and then you
enable core-dumps again because there *wasn't* a privilege change -
even if you're still at those elevated privileges.
Now, this is clearly not a Linux issue - we're just doing what others
have been doing too. But I think we should just admit that "what
others have been doing" is simply broken.
And yes, some odd situation migth be broken by this kind of change,
but I think this kind of "the old model was broken" may simply require
that. I suspect we can find a solution that fixes all the regular
cases.
Hmm?
I think this is a pretty clever idea. At least it is better than
resetting RLIMIT_CORE to 0. As it is all done within the kernel, there
is no need to change any userspace code. We may need to add a flag bit
in the task structure to indicate using the suid_dumpable setting so
that it can be inherited across fork/exec.
Thanks for the suggestion.
Cheers,
Longman
