From: Andi Kleen <email@example.com> To: John Wood <firstname.lastname@example.org> Cc: Kees Cook <email@example.com>, Jann Horn <firstname.lastname@example.org>, Jonathan Corbet <email@example.com>, James Morris <firstname.lastname@example.org>, "Serge E. Hallyn" <email@example.com>, Shuah Khan <firstname.lastname@example.org>, email@example.com, Greg Kroah-Hartman <firstname.lastname@example.org>, Randy Dunlap <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH v7 0/7] Fork brute force attack mitigation Date: Sun, 23 May 2021 07:43:16 -0700 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20210523073124.GA3762@ubuntu> 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? 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
next prev parent reply other threads:[~2021-05-23 14:43 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-21 17:24 John Wood 2021-05-21 17:24 ` [PATCH v7 1/7] security: Add LSM hook at the point where a task gets a fatal signal John Wood 2021-05-21 17:24 ` [PATCH v7 2/7] security/brute: Define a LSM and add sysctl attributes John Wood 2021-05-21 17:24 ` [PATCH v7 3/7] security/brute: Detect a brute force attack John Wood 2021-05-21 17:24 ` [PATCH v7 4/7] security/brute: Mitigate " John Wood 2021-05-21 18:02 ` [PATCH v7 0/7] Fork brute force attack mitigation Andi Kleen 2021-05-23 7:31 ` John Wood 2021-05-23 14:43 ` Andi Kleen [this message] 2021-05-23 15:47 ` John Wood 2021-05-22 6:35 ` [PATCH v7 5/7] selftests/brute: Add tests for the Brute LSM John Wood 2021-05-22 6:39 ` [PATCH v7 6/7] Documentation: Add documentation " John Wood 2021-05-22 6:44 ` [PATCH v7 7/7] MAINTAINERS: Add a new entry " John Wood
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v7 0/7] Fork brute force attack mitigation' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.