Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 23 May 2021 17:47:49 +0200
From:   John Wood <john.wood@gmx.com>
To:     Andi Kleen <ak@linux.intel.com>
Cc:     John Wood <john.wood@gmx.com>, Kees Cook <keescook@chromium.org>,
        Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>,
        James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Shuah Khan <shuah@kernel.org>, valdis.kletnieks@vt.edu,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-kselftest@vger.kernel.org, linux-hardening@vger.kernel.org,
        kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v7 0/7] Fork brute force attack mitigation
Message-ID: <20210523154749.GA3762@ubuntu>
References: <20210521172414.69456-1-john.wood@gmx.com>
 <19903478-52e0-3829-0515-3e17669108f7@linux.intel.com>
 <20210523073124.GA3762@ubuntu>
 <3d4ddd55-4f42-3ef7-dd68-a9f2bc33ba4b@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3d4ddd55-4f42-3ef7-dd68-a9f2bc33ba4b@linux.intel.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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 [2] related to the possibility that a supervi=
sor
> > > > respawns processes killed by the Brute LSM. He suggested adding so=
me 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 bru=
te xattr
> > > > of one executable and know if it is blocked by Brute and why (usin=
g the
> > > > statistical data).
> > > It looks better now, Thank.
> > >
> > > One potential problem is that the supervisor might see the executabl=
e
> > > directly, but run it through some wrapper. In fact I suspect that wi=
ll 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 wai=
t*
> > > chain, so that the supervisor can directly collect it. That would ne=
ed 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 tho=
ugh,
> that might need more research (my understanding is that modern superviso=
rs
> often use cgroups)

Yeah, a new topic to learn: cgroups. I will try to work on this too if the=
re are
no objections.

Thanks for the feedback.
John Wood