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:   Fri, 12 Mar 2021 17:19:21 +0100
From:   John Wood <john.wood@gmx.com>
To:     peter enderborg <peter.enderborg@sony.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>
Cc:     John Wood <john.wood@gmx.com>,
        "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 5/8] security/brute: Mitigate a brute force attack
Message-ID: <20210312161921.GA3103@ubuntu>
References: <20210227153013.6747-1-john.wood@gmx.com>
 <20210227153013.6747-6-john.wood@gmx.com>
 <5419ebe6-bb82-9b66-052b-0eefff93e5ae@sony.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5419ebe6-bb82-9b66-052b-0eefff93e5ae@sony.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi,

On Thu, Mar 11, 2021 at 09:32:47PM +0100, peter enderborg wrote:
> On 2/27/21 4:30 PM, John Wood wrote:
> > In order to mitigate a brute force attack all the offending tasks invo=
lved
> > in the attack must be killed. In other words, it is necessary to kill =
all
> > the tasks that share the fork and/or exec statistical data related to =
the
> > attack. Moreover, if the attack happens through the fork system call, =
the
> > processes that have the same group_leader that the current task (the t=
ask
> > that has crashed) must be avoided since they are in the path to be kil=
led.
> >
> > When the SIGKILL signal is sent to the offending tasks, the function
> > "brute_kill_offending_tasks" will be called in a recursive way from th=
e
> > task_fatal_signal LSM hook due to a small crash period. So, to avoid k=
ill
> > again the same tasks due to a recursive call of this function, it is
> > necessary to disable the attack detection for the involved hierarchies=
.
>
> Would it not be useful for forensic reasons to be able to send SIGABRT a=
nd get the a coredump?

If there are many tasks involved in the attack we will generate a big numb=
er of
coredumps (one per task aborted). This can be solved if we send the SIGABR=
T to
terminate the first process found and send SIGKILL to terminate the remain=
ing
processes. But I don't know if under this scenario we will get a core dump=
 with
lack of information (the info related to the other processes).

Another scenario:

The process that crashes is the last in the fork hierarchy and triggers a =
brute
force attack mitigation. In this case it it not necessary to kill the proc=
ess
that crashes since it is in the path to be killed. So, under this situatio=
n we
will not get a coredump (we don't send any signal). Lack of information ag=
ain.

Currently, we show the name of the task that triggers the mitigation, the =
attack
type (fork or exec) and the name and pid of all the offending tasks involv=
ed in
the attack (the tasks that we kill). If it's necessary we can show more in=
fo.
What info do you think would be necessary?

Thanks,
John Wood