Notify special task kill using wait* functions

[John Wood]

Hi,

On Sat, Apr 03, 2021 at 05:34:01PM -0400, Valdis Klētnieks wrote:
> On Sat, 03 Apr 2021 09:02:26 +0200, John Wood said:
>
> > 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.
>
> So how do you figure out how far up the chain you kill processes?

When a process crashes with a fatal signal their stats are updated. Also,
are updated the "exec" stats (the statistics of the parent process: the
process that called the execve system call).

Then the stats of the process that crashes are checked. If these show a
fast crash rate, this fork hierarchy is killed (all the processes that
have the same stats). Then the exec stats are checked but if the info are
equal to the fork stats nothing is done. Otherwise, if they show an attack,
this fork hierarchy is also killed.

If you follow the discussion with Andi Kleen there is a full example. [1]

[1] https://lore.kernel.org/kernel-hardening/20210309184054.GA3058@ubuntu/

Now, the process that forks and crashes is mitigated. Also, the process
that exec and the child crashes is mitigated. The only drawback here, as
point Andi, is that a supervisor respawns some process killed. To avoid
this situation he suggest to notify to usersapace via wait* that the
task has been killed by "brute". Then, this supervisor has the chance to
do what they need (respawn or not).

> What does a triple or quadruple fork do? How do you ensure that you deliver
> the notification to the correct supervisor? (Hint - walking backwards until you
> hit a process running as root isn't necessarily the right answer, especially
> once you consider containers and systems where gdm runs as non-root
> and other weird stuff..)

The number of forks does not matter. It's not a problem here. And, if you
follow the annotated discussion, you will see that walking backwards not
necessary reach init.

The notification is delivered to the supervisor that wants it (via wait).

> Bonus points if you deal correctly with abuse of LD_PRELOAD to front-end
> a signal handler that catches SIGSEGV, without breaking the semantics
> of legitimate signal handlers...

Hmm, interesting... I need to study it and test. Good point. Thanks.

Thanks,
John Wood