Notify special task kill using wait* functions

[John Wood]

Hi,

On Fri, Apr 02, 2021 at 11:50:18PM -0400, Valdis Klētnieks wrote:
> On Fri, 02 Apr 2021 14:49:32 +0200, John Wood said:
>
> > the attack can be started again. So, he suggested that notifying to userspace
> > (via wait*() functions) that a child task has been killed by the "Brute" LSM,
> > the supervisor can adopt the correct policy and avoid respawn the killed
> > processes.
>
> > [1] https://lore.kernel.org/kernel-hardening/20210227153013.6747-8-john.wood@gmx.com/
>
> That patch contains the biggest problem with your idea:
>
> +Moreover, this method is based on the idea that the protection doesn't act if
> +the parent crashes. So, it would still be possible for an attacker to fork a
> +process and probe itself. Then, fork the child process and probe itself again.
> +This way, these steps can be repeated infinite times without any mitigation.

Sorry, but this paragraph is extracted from the "Other implementations" section
(grsecurity to be more clear). Concreatly from the "Scenarios not detected
(false negatives)". So, it is a problem that has been addressed with the current
implementation. In other words, the "Brute LSM" acts on the parent (brute force
attack through the execve system call).

> In general, "security" that has an obvious and easy way to bypass it isn't
> providing any real security at all. If all it takes to bypass it is a double fork,
> everybody who didn't just fall out of the tree will do a double fork.  In other
> words, anybody who's clued enough to write malware that actually works
> and does the sort of attack you're trying to prevent should be able to fix
> the malware to bypass your "security" with just a few added lines of code.

Currently, the scenario you propose is fully mitigated :). And notifying to
userspace that all the tasks has been killed by "Brute" not decrease the
security. It adds the possibility that the supervisor adopts the correct policy.

If you can bypass it send a proof of concept and I will try to improve the
implementation :)

Thanks,
John Wood