Messages in this thread | | | Date | Tue, 21 Dec 2021 14:27:47 -0500 | Subject | Re: [PATCH] exec: Make suid_dumpable apply to SUID/SGID binaries irrespective of invoking users | From | Waiman Long <> |
| |
On 12/21/21 13:19, Linus Torvalds wrote: > On Tue, Dec 21, 2021 at 10:01 AM Waiman Long <longman@redhat.com> 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
| |