archive mirror
 help / color / mirror / Atom feed
From: John Wood <>
To: Andi Kleen <>
Cc: John Wood <>, Kees Cook <>,
	Jann Horn <>,
	Randy Dunlap <>,
	Jonathan Corbet <>,
	James Morris <>, Shuah Khan <>,
	"Serge E. Hallyn" <>,
	Greg Kroah-Hartman <>,,,,,
Subject: Re: [PATCH v5 7/8] Documentation: Add documentation for the Brute LSM
Date: Tue, 2 Mar 2021 19:31:05 +0100	[thread overview]
Message-ID: <20210302183032.GA3049@ubuntu> (raw)
In-Reply-To: <>

On Sun, Feb 28, 2021 at 10:56:45AM -0800, Andi Kleen wrote:
> John Wood <> 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.

The statistics shared by all the fork hierarchy processes are hold by the
"brute_stats" struct.

struct brute_cred {
	kuid_t uid;
	kgid_t gid;
	kuid_t suid;
	kgid_t sgid;
	kuid_t euid;
	kgid_t egid;
	kuid_t fsuid;
	kgid_t fsgid;

struct brute_stats {
	spinlock_t lock;
	refcount_t refc;
	unsigned char faults;
	u64 jiffies;
	u64 period;
	struct brute_cred saved_cred;
	unsigned char network : 1;
	unsigned char bounds_crossed : 1;

This is a fixed size struct where, in every process crash (due to a fatal
signal), the application crash period (period field) is updated on an on going
basis using an exponential moving average (this way it is not necessary to save
the old crash period values). The jiffies and faults fields complete the
statistics basic info. The saved_cred field is used to fine tuning the detection
(detect if the privileges have changed) and also is fixed size. And the
remaining flags are also used to narrow the detection (detect if a privilege
boundary has been crossed).

> How much is the worst case extra memory consumption?

In every fork system call the parent statistics are shared with the child
process. In every execve system call a new brute_stats struct is allocated. So,
only one brute_stats struct is allocated for every fork hierarchy (hierarchy of
processes from the execve system call). The more processes are running, the more
memory will be used.

> 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.

When a process crashes due to a fatal signal delivered by the kernel (with some
user signal exceptions) the statistics shared by this process with all the fork
hierarchy processes are updated. This allow us to detect a brute force attack
through the "fork" system call. If these statistics show a fast crash rate a
mitigation is triggered. Also, these statistics are removed when all the
processes in this hierarchy have finished.

But at the same time these statistics are updated, also are updated the
statistics of the parent fork hierarchy (the statistics shared by the process
that "exec" the child process annotated in the last paragraph). This way a brute
force attack through the "execve" system call can be detected. Also, if this
new statistics show a fast crash rate the mitigation is triggered.

> Do I miss something here? How is that mitigated?

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 statistics
(statistics showing a fast crash rate) are killed.

> Instead of discussing all the low level tedious details of the
> statistics it would be better to focus on these "high level"
> problems here.

Thanks for the advise. I will improve the documentation adding these high level

> -Andi

I hope this info clarify your questions. If not, I will try again.

John Wood

  reply	other threads:[~2021-03-02 18:31 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
2021-03-02 18:31     ` John Wood [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210302183032.GA3049@ubuntu \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v5 7/8] Documentation: Add documentation for the Brute LSM' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).