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, 7 Mar 2021 17:45:20 +0100
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>,
        Randy Dunlap <rdunlap@infradead.org>,
        Jonathan Corbet <corbet@lwn.net>,
        James Morris <jmorris@namei.org>,
        Shuah Khan <shuah@kernel.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-kselftest@vger.kernel.org,
        kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v5 7/8] Documentation: Add documentation for the Brute LSM
Message-ID: <20210307164520.GA16296@ubuntu>
References: <20210227153013.6747-1-john.wood@gmx.com>
 <20210227153013.6747-8-john.wood@gmx.com>
 <878s78dnrm.fsf@linux.intel.com>
 <20210302183032.GA3049@ubuntu>
 <20210307151920.GR472138@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210307151920.GR472138@tassilo.jf.intel.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Mar 07, 2021 at 07:19:20AM -0800, Andi Kleen wrote:
> Sorry for the late answer. I somehow missed your email earlier.
>
> > As a mitigation method, all the offending tasks involved in the attack=
 are
> > killed. Or in other words, all the tasks that share the same statistic=
s
> > (statistics showing a fast crash rate) are killed.
>
> So systemd will just restart the network daemon and then the attack work=
s
> again?

Sorry, but I think my last explanation is not clear enough. If the network
daemon crashes repeatedly in a short period of time it will trigger a brut=
e
force attack through the fork system call. Then this daemon and all the fo=
rk
processes created from it will be killed. If the systemd restart the netwo=
rk
daemon and it will crash again, then the systemd will be killed. I think t=
his
way the attack is fully mitigated.

> Or if it's a interactive login you log in again.

First the login will be killed (if it fails with a fatal signal) and if it=
 is
restarted, the process that exec() it again will be killed. In this case I=
 think
that the threat is also completely mitigated.

> I think it might be useful even with these limitations, but it would
> be good to spell out the limitations of the method more clearly.
>
> I suspect to be useful it'll likely need some user space configuration
> changes too.

In the v2 version there were some sysctl attributes to fine tuning the
detection. The following two paragraph are extracted from the documentatio=
n
patch of this version:

To customize the detection's sensibility there are two new sysctl attribut=
es
that allow to set the last crashes timestamps list size and the applicatio=
n
crash period threshold (in milliseconds). Both are accessible through the
following files respectively.

/proc/sys/kernel/brute/timestamps_list_size
/proc/sys/kernel/brute/crash_period_threshold

However, Kees Cook suggested that if we narrow the attack detection focusi=
ng in
the crossing of privilege boundaries and signals delivered only by the ker=
nel,
it seems not necessary the customization of this feature by the user. I ag=
gree
with that.

>
> -Andi

I have sent a v6 version with the documentation improved.

Thanks for your comments,
John Wood