Date: Sun, 23 May 2021 17:47:49 +0200 From: John Wood <john.wood@....com> To: Andi Kleen <ak@...ux.intel.com> Cc: John Wood <john.wood@....com>, Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, Shuah Khan <shuah@...nel.org>, valdis.kletnieks@...edu, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Randy Dunlap <rdunlap@...radead.org>, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, linux-kselftest@...r.kernel.org, linux-hardening@...r.kernel.org, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH v7 0/7] Fork brute force attack mitigation On Sun, May 23, 2021 at 07:43:16AM -0700, Andi Kleen wrote: > > On 5/23/2021 12:31 AM, John Wood wrote: > > Hi, > > > > On Fri, May 21, 2021 at 11:02:14AM -0700, Andi Kleen wrote: > > > > Moreover, I think this solves another problem pointed out by Andi Kleen > > > > during the v5 review  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? Yes, this is the idea. (but now is a work in progress :) ) > Assuming it does, for SIGCHLD it seems reasonable. So, if there are no objections I will work on it for the next version. > > 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) Yeah, a new topic to learn: cgroups. I will try to work on this too if there are no objections. Thanks for the feedback. John Wood
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.