linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Wood <john.wood@gmx.com>
To: Kees Cook <keescook@chromium.org>
Cc: kernel-hardening@lists.openwall.com, Jann Horn <jannh@google.com>,
	John Wood <john.wood@gmx.com>,
	Matthew Wilcox <willy@infradead.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Iurii Zaikin <yzaikin@google.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH 6/6] security/fbfam: Mitigate a fork brute force attack
Date: Fri, 18 Sep 2020 18:02:16 +0200	[thread overview]
Message-ID: <20200918152116.GB3229@ubuntu> (raw)
In-Reply-To: <202009101649.2A0BF95@keescook>

On Thu, Sep 10, 2020 at 04:56:19PM -0700, Kees Cook wrote:
> On Thu, Sep 10, 2020 at 01:21:07PM -0700, Kees Cook wrote:
> >  /**
> > + * fbfam_kill_tasks() - Kill the offending tasks
> > + *
> > + * When a fork brute force attack is detected it is necessary to kill all the
> > + * offending tasks. Since this function is called from fbfam_handle_attack(),
> > + * and so, every time a core dump is triggered, only is needed to kill the
> > + * others tasks that share the same statistical data, not the current one as
> > + * this is in the path to be killed.
> > + *
> > + * When the SIGKILL signal is sent to the offending tasks, this function will be
> > + * called again during the core dump due to the shared statistical data shows a
> > + * quickly crashing rate. So, to avoid kill again the same tasks due to a
> > + * recursive call of this function, it is necessary to disable the attack
> > + * detection setting the jiffies to zero.
> > + *
> > + * To improve the for_each_process loop it is possible to end it when all the
> > + * tasks that shared the same statistics are found.
> > + *
> > + * Return: -EFAULT if the current task doesn't have statistical data. Zero
> > + *         otherwise.
> > + */
> > +static int fbfam_kill_tasks(void)
> > +{
> > +	struct fbfam_stats *stats = current->fbfam_stats;
> > +	struct task_struct *p;
> > +	unsigned int to_kill, killed = 0;
> > +
> > +	if (!stats)
> > +		return -EFAULT;
> > +
> > +	to_kill = refcount_read(&stats->refc) - 1;
> > +	if (!to_kill)
> > +		return 0;
> > +
> > +	/* Disable the attack detection */
> > +	stats->jiffies = 0;
> > +	rcu_read_lock();
> > +
> > +	for_each_process(p) {
> > +		if (p == current || p->fbfam_stats != stats)
> > +			continue;
> > +
> > +		do_send_sig_info(SIGKILL, SEND_SIG_PRIV, p, PIDTYPE_PID);
> > +		pr_warn("fbfam: Offending process with PID %d killed\n",
> > +			p->pid);
>
> I'd make this ratelimited (along with Jann's suggestions).

Sorry, but I don't understand what you mean with "make this ratelimited".
A clarification would be greatly appreciated.

> Also, instead of the explicit "fbfam:" prefix, use the regular
> prefixing method:
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Understood.

> > +
> > +		killed += 1;
> > +		if (killed >= to_kill)
> > +			break;
> > +	}
> > +
> > +	rcu_read_unlock();
>
> Can't newly created processes escape this RCU read lock? I think this
> need alternate locking, or something in the task_alloc hook that will
> block any new process from being created within the stats group.

I will work on this for the next version. Thanks.

> > +	return 0;
> > +}
>
> --
> Kees Cook

Thanks
John Wood

  parent reply	other threads:[~2020-09-18 16:09 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10 20:21 [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam) Kees Cook
2020-09-10 20:21 ` [RFC PATCH 1/6] security/fbfam: Add a Kconfig to enable the fbfam feature Kees Cook
2020-09-10 21:21   ` Jann Horn
2020-09-17 17:32     ` John Wood
2020-09-10 23:18   ` Kees Cook
2020-09-17 18:40     ` John Wood
2020-09-17 22:05       ` Kees Cook
2020-09-18 14:50         ` John Wood
2020-09-10 20:21 ` [RFC PATCH 2/6] security/fbfam: Add the api to manage statistics Kees Cook
2020-09-10 23:23   ` Kees Cook
2020-09-10 20:21 ` [RFC PATCH 3/6] security/fbfam: Use " Kees Cook
2020-09-10 20:27   ` Jann Horn
2020-09-10 23:33   ` Kees Cook
2020-09-29 23:47     ` Steven Rostedt
2020-09-29 23:49       ` Steven Rostedt
2020-10-03  9:52         ` John Wood
2020-09-10 20:21 ` [RFC PATCH 4/6] security/fbfam: Add a new sysctl to control the crashing rate threshold Kees Cook
2020-09-10 23:14   ` Kees Cook
2020-09-13 14:33     ` John Wood
2020-09-10 20:21 ` [RFC PATCH 5/6] security/fbfam: Detect a fork brute force attack Kees Cook
2020-09-10 21:10   ` Jann Horn
2020-09-13 17:54     ` John Wood
2020-09-14 19:42       ` Jann Horn
2020-09-15 18:44         ` John Wood
2020-09-10 23:49   ` Kees Cook
2020-09-11  0:01     ` Jann Horn
2020-09-13 16:56       ` John Wood
2020-09-14 19:39         ` Jann Horn
2020-09-15 17:36           ` John Wood
2020-09-10 20:21 ` [RFC PATCH 6/6] security/fbfam: Mitigate " Kees Cook
2020-09-10 20:55   ` Jann Horn
2020-09-10 23:56   ` Kees Cook
2020-09-11  0:20     ` Jann Horn
2020-09-18 16:02     ` John Wood [this message]
2020-09-18 21:35       ` Kees Cook
2020-09-19  8:01         ` John Wood
2020-09-10 20:39 ` [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam) Jann Horn
2020-09-10 23:58 ` Kees Cook
2020-09-11 14:48   ` John Wood
2020-09-12  7:55     ` Kees Cook
2020-09-12 12:24       ` John Wood
2020-09-12  0:03 ` James Morris
2020-09-12  7:56   ` Kees Cook
2020-09-12  9:36     ` John Wood
2020-09-12 14:47       ` Mel Gorman
2020-09-12 20:48         ` Ondrej Mosnacek
2020-09-13  7:24           ` 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=20200918152116.GB3229@ubuntu \
    --to=john.wood@gmx.com \
    --cc=bsegall@google.com \
    --cc=corbet@lwn.net \
    --cc=dietmar.eggemann@arm.com \
    --cc=jannh@google.com \
    --cc=jmorris@namei.org \
    --cc=juri.lelli@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=serge@hallyn.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=yzaikin@google.com \
    /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).