On Tue, Dec 21, 2021 at 02:27:47PM -0500, Waiman Long wrote: > 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. Another problem that was raised when discussing RLIMIT_CORE to zero was the loss of the old value. > 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. Depending on what we change there can be some subtly visible changes. In one of my servers I explicitly re-enable dumpable before setsid() when a core dump is desired for debugging. But other deamons could do the exact opposite. If setsid() systematically restores suid_dumpable, a process that explicitly disables it before calling setsid() would see it come back. But if we have a special "suid_in_progress" flag to mask suid_dumpable and that's reset by setsid() and possibly prctl(PR_SET_DUMPABLE) then I think it could even cover that unlikely case. Just my two cents, Willy
