Hi Valdis, On Tue, Apr 06, 2021 at 07:55:36PM -0400, Valdis Klētnieks wrote: > On Mon, 05 Apr 2021 09:31:47 +0200, John Wood said: > > > > And how does the kernel know that it's notifying a "real" supervisor process, > > > and not a process started by the bad guy, who can receive the notification > > > and decide to respawn? > > > > > Well, I think this is not possible to know. Anyway, I believe that the "bad > > guy" not rely on the wait* notification to decide to respawn or not. He > > will do the attack without waiting any notification. > > You believe wrong. After my 4 decades of interacting with the computer security > community, the only thing that remains a constant is that if you say "I believe > that...", there will be *somebody* who will say "Challenge accepted" and try to > do the opposite just for the lulz. Then there will be a second guy saying "Hmm.. > I wonder how much I could sell a 0-day for..." Ok, lesson learned. I agree. > [Great explanation and information] Wow, I'm impressed. Thank you very much for this great explanation and info. Thanks a lot for do that (insist about this subject). During the discussion [1] you made me realize that I'm totally wrong (and you are totally right :) ). The detection of brute force attacks that happen through the execve system call can be easily bypassed -> Well, I bypass it during the tests using a double exec. So, this part needs more work. [1] https://lore.kernel.org/kernelnewbies/20210330173459.GA3163@ubuntu/ A first thought: Scenario: A process [p1] execs. The child [p2] execs again. The child [p3] crashes. Problem: The brute LSM kills p3 if it forks and crashes with a fast crash rate (fork brute force attack). But the p2 process can start again the p3. Then brute kills p2 (exec brute force attack). Now, if p1 starts p2 the attack can follow without mitigation. New proposal: When brute detects a brute force attack through the fork system call (killing p3) it will mark the binary file executed by p3 as "not allowed". >From now on, any execve that try to run this binary will fail. This way it is not necessary to notify nothing to userspace and also we avoid an exec brute force attack due to the respawn of processes [2] by a supervisor (abused or not by a bad guy). [2] https://lore.kernel.org/kernel-hardening/878s78dnrm.fsf@xxxxxxxxxxxxxxx/ This would imply remove the update (walking up in the processes tree) of the exec stats and add a list of not allowed binaries. What do you think? Any ideas are welcome. I'm open minded :) Regards, John Wood
