All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Wood <john.wood@gmx.com>
To: Randy Dunlap <rdunlap@infradead.org>,
	Kees Cook <keescook@chromium.org>, Jann Horn <jannh@google.com>,
	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
Subject: Re: [PATCH v3 3/8] securtiy/brute: Detect a brute force attack
Date: Tue, 23 Feb 2021 19:13:57 +0100	[thread overview]
Message-ID: <20210223181357.GA3068@ubuntu> (raw)
In-Reply-To: <085f8f05-243e-fbf0-3f9c-ea011511a296@infradead.org>

Hi,

On Sun, Feb 21, 2021 at 06:25:51PM -0800, Randy Dunlap wrote:
> Hi--
>
> On 2/21/21 7:49 AM, John Wood wrote:
> >
> > +/**
> > + * print_fork_attack_running() - Warn about a fork brute force attack.
> > + */
> > +static inline void print_fork_attack_running(void)
> > +{
> > +	pr_warn("Fork brute force attack detected [%s]\n", current->comm);
> > +}
>
> Do these pr_warn() calls need to be rate-limited so that they don't
> flood the kernel log?

I think it is not necessary since when a brute force attack through the fork
system call is detected, a fork warning appears only once. Then, all the
offending tasks involved in the attack are killed. But if the parent try to run
again the same app already killed, a new crash will trigger a brute force attack
through the execve system call, then this parent is killed, and a new warning
message appears. Now, the parent and childs are killed, the attacks are
mitigated and only a few messages (one or two) have been shown in the kernel
log.

Thanks,
John Wood

> > +/**
> > + * print_exec_attack_running() - Warn about an exec brute force attack.
> > + * @stats: Statistical data shared by all the fork hierarchy processes.
> > + *
> > + * The statistical data shared by all the fork hierarchy processes cannot be
> > + * NULL.
> > + *
> > + * Before showing the process name it is mandatory to find a process that holds
> > + * a pointer to the exec statistics.
> > + *
> > + * Context: Must be called with tasklist_lock and brute_stats_ptr_lock held.
> > + */
> > +static void print_exec_attack_running(const struct brute_stats *stats)
> > +{
> > +	struct task_struct *p;
> > +	struct brute_stats **p_stats;
> > +	bool found = false;
> > +
> > +	for_each_process(p) {
> > +		p_stats = brute_stats_ptr(p);
> > +		if (*p_stats == stats) {
> > +			found = true;
> > +			break;
> > +		}
> >  	}
> > +
> > +	if (WARN(!found, "No exec process\n"))
> > +		return;
> > +
> > +	pr_warn("Exec brute force attack detected [%s]\n", p->comm);
> > +}
>
>
> thanks.
> --
> ~Randy
>

  reply	other threads:[~2021-02-23 18:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-21 15:49 [PATCH v3 0/8] Fork brute force attack mitigation John Wood
2021-02-21 15:49 ` [PATCH v3 1/8] security: Add LSM hook at the point where a task gets a fatal signal John Wood
2021-02-21 15:49 ` [PATCH v3 2/8] security/brute: Define a LSM and manage statistical data John Wood
2021-02-21 15:49 ` [PATCH v3 3/8] securtiy/brute: Detect a brute force attack John Wood
2021-02-22  2:25   ` Randy Dunlap
2021-02-23 18:13     ` John Wood [this message]
2021-02-22  2:30   ` Randy Dunlap
2021-02-23 18:25     ` John Wood
2021-02-22  2:47   ` Randy Dunlap
2021-02-23 18:20     ` John Wood
2021-02-23 20:44       ` Randy Dunlap
2021-02-21 15:49 ` [PATCH v3 4/8] security/brute: Fine tuning the attack detection John Wood
2021-02-21 15:49 ` [PATCH v3 5/8] security/brute: Mitigate a brute force attack John Wood
2021-02-21 15:49 ` [PATCH v3 6/8] selftests/brute: Add tests for the Brute LSM John Wood
2021-02-21 15:49 ` [PATCH v3 7/8] Documentation: Add documentation " John Wood
2021-02-21 15:49 ` [PATCH v3 8/8] MAINTAINERS: Add a new entry " 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=20210223181357.GA3068@ubuntu \
    --to=john.wood@gmx.com \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.