From: Andi Kleen <ak@linux.intel.com>
To: John Wood <john.wood@gmx.com>
Cc: 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
Date: Sun, 28 Feb 2021 10:56:45 -0800 [thread overview]
Message-ID: <878s78dnrm.fsf@linux.intel.com> (raw)
In-Reply-To: <20210227153013.6747-8-john.wood@gmx.com> (John Wood's message of "Sat, 27 Feb 2021 16:30:12 +0100")
John Wood <john.wood@gmx.com> writes:
> +
> +To detect a brute force attack it is necessary that the statistics shared by all
> +the fork hierarchy processes be updated in every fatal crash and the most
> +important data to update is the application crash period.
So I haven't really followed the discussion and also not completely read
the patches (so apologies if that was already explained or is documented
somewhere else).
But what I'm missing here is some indication how much
memory these statistics can use up and how are they limited.
How much is the worst case extra memory consumption?
If there is no limit how is DoS prevented?
If there is a limit, there likely needs to be a way to throw out
information, and so the attack would just shift to forcing the kernel
to throw out this information before retrying.
e.g. if the data is hold for the parent shell: restart the parent
shell all the time.
e.g. if the data is hold for the sshd daemon used to log in:
Somehow cause sshd to respawn to discard the statistics.
Do I miss something here? How is that mitigated?
Instead of discussing all the low level tedious details of the
statistics it would be better to focus on these "high level"
problems here.
-Andi
next prev parent reply other threads:[~2021-02-28 18:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-27 15:30 [PATCH v5 0/8] Fork brute force attack mitigation John Wood
2021-02-27 15:30 ` [PATCH v5 1/8] security: Add LSM hook at the point where a task gets a fatal signal John Wood
2021-02-27 15:30 ` [PATCH v5 2/8] security/brute: Define a LSM and manage statistical data John Wood
2021-03-02 5:49 ` [security/brute] cfe92ab6a3: WARNING:inconsistent_lock_state kernel test robot
2021-03-02 18:39 ` John Wood
2021-02-27 15:30 ` [PATCH v5 3/8] securtiy/brute: Detect a brute force attack John Wood
2021-02-27 15:30 ` [PATCH v5 4/8] security/brute: Fine tuning the attack detection John Wood
2021-02-27 15:30 ` [PATCH v5 5/8] security/brute: Mitigate a brute force attack John Wood
2021-03-11 20:32 ` peter enderborg
2021-03-12 16:19 ` John Wood
2021-02-27 15:30 ` [PATCH v5 6/8] selftests/brute: Add tests for the Brute LSM John Wood
2021-02-27 15:30 ` [PATCH v5 7/8] Documentation: Add documentation " John Wood
2021-02-28 18:56 ` Andi Kleen [this message]
2021-03-02 18:31 ` John Wood
2021-03-07 15:19 ` Andi Kleen
2021-03-07 16:45 ` John Wood
2021-03-07 17:25 ` Andi Kleen
2021-03-07 18:05 ` John Wood
2021-03-07 22:49 ` Andi Kleen
2021-03-09 18:40 ` John Wood
2021-03-11 18:22 ` John Wood
2021-03-11 20:08 ` Andi Kleen
2021-03-12 17:47 ` John Wood
2021-03-11 20:05 ` Andi Kleen
2021-03-12 17:54 ` John Wood
2021-02-27 15:30 ` [PATCH v5 8/8] MAINTAINERS: Add a new entry " John Wood
2021-02-27 18:44 ` [PATCH v5 0/8] Fork brute force attack mitigation 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 \
--in-reply-to=878s78dnrm.fsf@linux.intel.com \
--to=ak@linux.intel.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=john.wood@gmx.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).