Message-ID: <20111103200856.GK21134@count0.beaverton.ibm.com>
Date:	Thu, 3 Nov 2011 13:08:56 -0700
From:	Matt Helsley <matthltc@...ibm.com>
To:	Glauber Costa <glommer@...allels.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH] new cgroup controller "fork"

On Thu, Nov 03, 2011 at 04:56:38PM -0200, Glauber Costa wrote:
> On 11/03/2011 04:51 PM, Max Kellermann wrote:
> >On 2011/11/03 19:21, Alan Cox<alan@...rguk.ukuu.org.uk>  wrote:
> >>>After little discussion, nobody seemed to be interested in it, and
> >>>nobody merged it.  I reposted it today, not knowing somebody else had
> >>>come up with a similar idea meanwhile.
> >>
> >>I don't really see a meaningful use case for this. Why should millions of
> >>users have this stuff in their kernel. What's the general purpose use
> >>case we should all be excited about ?
> >
> >Putting a reasonable limit on jobs that are expected to run only for a
> >limited amount of time, with a limited amount of total resources.  For
> >example: CGI, cron jobs, backup, munin plugins, virus scanners and
> >other email filters, procmail, ... - when the job is done, the group
> >can be deleted, and new instances will run in a new group.
> >
> >With just RLIMIT_NPROC or task_counter, you can limit the total number
> >of processes, but it will not stop a fork bomb - it will only slow it
> >down.  The fork bomb will still bounce between 1 and the limit, and
> >consume lots of resources for forking and exiting.
> >
> >(Glauber: the above should answer your last email, too)
> 
> Yet, the damage a fork bomb can pose into the system this way is
> severely limited. Combined with the cpu controller to guarantee that
> this group of process will never take the whole cpu for themselves,
> you have almost everything you need, if not everything.

Assuming we're only talking about fork bombs, I tend to agree.
Using Frederic's cgroup subsystem we can adjust the limit to the number of
legitimate tasks in the cgroup (0 if you can't distinguish them) and then
start killing the fork bombs. If the forkbomb goes into a fork-then-exit
loop in order to eat cpu once it's reached the task limit the cpu
controller becomes more useful.

However, isn't it possible that forking an extra task could be a sign of
a security issue other than a fork bomb? Imagine a CGI module that could
set the fork limit (not number of tasks) to the precise or maximum
number of tasks that CGI script should create (perhaps a per-script
limit known and configured somewhere by an admin). If the CGI script
attempts to go over that limit it could be a sign of an exploit attempt.
The fork limit could prevent the CGI script from creating a shell with
unintended privileges. Or the shell might be created but no non-builtin
commands could be executed. The exploit would not be able to kill an
existing task to make room. Anyhow, that's purely hypothetical --
I can imagine a use for this feature but I don't know that it's
been implemented or how practical it really is. Also, depending on how
such a CGI module+script drops privileges, there still may be acceptable
alternatives like syscall filtering...

Cheers,
	-Matt Helsley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists