LWN: Comments on "Handling brute force attacks in the kernel"

Handling brute force attacks in the kernel

jch — Wed, 31 Mar 2021 13:21:17 +0000

Why does it kill the process hierarchy rather than just causing fork to fail?

Handling brute force attacks in the kernel

smurf — Fri, 19 Mar 2021 07:36:20 +0000

So? The failing child will then log the problem and exit. It will not die with a segfault or similar, thus it won't trigger Brute.

Handling brute force attacks in the kernel

Cyberax — Fri, 19 Mar 2021 05:45:38 +0000

Not necessarily, if exec() fails for some reason. E.g. a binfmt handler was accidentally removed and foreign binaries can no longer run (happened to me a while ago when I was testing a cross-image).

Handling brute force attacks in the kernel

dtlin — Fri, 19 Mar 2021 05:43:49 +0000

Wouldn't they die after exec, thus not sharing memory layout and not triggering this mitigation?

Handling brute force attacks in the kernel

rahulsundaram — Thu, 18 Mar 2021 23:41:31 +0000

> I hardly understand what is 'assosiated process'.

I think that's answered in the article as well. Look for 'fork'.

Handling brute force attacks in the kernel

Cyberax — Thu, 18 Mar 2021 23:11:00 +0000

> For "slow brute force" variants, the absolute number of crashes in the hierarchy is compared against a threshold of 200. Some way to configure these values would seem like a desirable addition to Brute.
I can't wait for a bug report with a description: "Finally, a thing that has killed systemd for good!" because systemd had to restart a lot of failing daemons in short order.

Handling brute force attacks in the kernel

amarao — Thu, 18 Mar 2021 23:02:26 +0000

I hardly understand what is 'assosiated process'. My shell? My session? My seat? X server? Guilty by association, I suppose. Should software in a pacemaker of that loosy programmer to be included in the 'assosiated list'?

Handling brute force attacks in the kernel

rahulsundaram — Thu, 18 Mar 2021 22:51:37 +0000

From the article: "Brute kills all of the processes associated with the attack" - does this not answer your question?

Handling brute force attacks in the kernel

amarao — Thu, 18 Mar 2021 22:46:02 +0000

Can I ask avout consequences of such protection? If I'm a loosy programmer and my freshly written program had crashed 200 times, what penalty waits me?

Killing my shell, my editor, my dog, or what?

Handling brute force attacks in the kernel

walters — Thu, 18 Mar 2021 12:55:20 +0000

I haven't followed closely, but https://lwn.net/Articles/808048/ seems a lot more promising to me because it allows lifting all these heuristics out of the kernel - a hybrid eBPF + userspace process can access more semantic information; say things like "did this process receive packets from an untrusted network recently". And it can be much more configurable, e.g. one could easily recode it to force a process like this to dump core for offline analysis instead, etc.

Et tu, Brute?

istenrot — Thu, 18 Mar 2021 10:08:09 +0000

You can always build your own kernel with LSM modules of your choice.

Et tu, Brute?

ale2018 — Thu, 18 Mar 2021 09:49:23 +0000

I wish using LSM as a common frame supported an option to disable all of such modules with a single stroke.

Security is undoubtedly a necessity, and security modules are certainly useful for many users. However, I fear the moment when I'll have to spend hours to understand why something doesn't work until finally resolving to add "brute=0" right after "apparmor=0" on GRUB_CMDLINE_LINUX.