Thread (12 messages) 12 messages, 2 authors, 2021-05-23

Re: [PATCH v7 0/7] Fork brute force attack mitigation

From: Andi Kleen <hidden>
Date: 2021-05-23 14:43:21
Also in: linux-doc, linux-hardening, linux-kselftest, lkml

On 5/23/2021 12:31 AM, John Wood wrote:
Hi,

On Fri, May 21, 2021 at 11:02:14AM -0700, Andi Kleen wrote:
quoted
quoted
Moreover, I think this solves another problem pointed out by Andi Kleen
during the v5 review [2] related to the possibility that a supervisor
respawns processes killed by the Brute LSM. He suggested adding some way so
a supervisor can know that a process has been killed by Brute and then
decide to respawn or not. So, now, the supervisor can read the brute xattr
of one executable and know if it is blocked by Brute and why (using the
statistical data).
It looks better now, Thank.

One potential problem is that the supervisor might see the executable
directly, but run it through some wrapper. In fact I suspect that will be
fairly common with complex daemons. So it couldn't directly look at the
xattr. Might be useful to also pass this information through the wait*
chain, so that the supervisor can directly collect it. That would need some
extension to these system calls.
Could something like this help? (not tested)
This works even when someone further down the chain died? Assuming it 
does, for SIGCHLD it seems reasonable.

I'm not fully sure how it will interact with cgroup release tracking 
though, that might need more research (my understanding is that modern 
supervisors often use cgroups)

-Andi

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help