Message-ID: <46D5794D.7030507@redhat.com>
Date:	Wed, 29 Aug 2007 09:49:01 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Anand Jahagirdar <anandjigar@...il.com>
CC:	Simon Arlott <simon@...e.lp0.eu>, Krzysztof Halasa <khc@...waw.pl>,
	linux-kernel@...r.kernel.org
Subject: Re: Fork Bombing Patch

Anand Jahagirdar wrote:
> Hi
>    consider a case:
> if non root user request admin for more number of processes than root
> user,admin needs to modify settings in /etc/security/limits.conf file
> and if that user is not trustworthy and if does fork bombing attack it
> will kill the box.

If root is dumb enough to give the user whatever privileges they ask for, 
fork-bombing is the least of your problems.

> (I have already tried this attack). in that case this loop will work,
> but by the time attack might have killed the box (Bcoz so many
> processes has already been created at that time) . so in that case
> admin wont come to know that what has happened.

On large multi-user SMP systems, the default ulimits will keep the box 
responsive, if sluggish.  Perhaps you should file a bug with your distribution 
if you believe the default settings in limits.conf are too high.  There's no way 
to algorithmically distinguish a forkbomb from a legitimate highly-threaded 
workload.

> Like this there are many cases..(actually these cases has already been
> discussed On LKML 2 months before in my thread named "fork bombing
> attack").
> in all these cases this printk helps adminstrator a lot.

What exactly does this patch help the administrator do?  If a box is thrashing, 
you still have sysrq.  You can also use cpusets and taskset to put your root 
login session on a dedicated processor, which is getting to be pretty cheap on 
modern many-core, many-thread systems.  Group scheduling is in the oven, which 
will allow you to prioritize classes of users in a more general manner, even on 
UP systems.

> On 8/29/07, Simon Arlott <simon@...e.lp0.eu> wrote:
>> On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
>>> Hi
>>>                 printk_ratelimit function takes care of flooding the
>>> syslog. due to printk_ratelimit function syslog will not be flooded

Um, no.  printk_ratelimit is on the order of *seconds*.  This prevents error 
conditions from causing the system to spend all of its CPU and I/O time logging. 
  It does very little to prevent log spamming.  If I sent you an email every 
second, it would make it much more difficult for you to find other messages in 
your inbox.  It's possible (easy, even) to write a forkbomber that doesn't 
actually harm system responsiveness, but will still trigger this printk as fast 
as possible.  If we merge this patch, every cracking toolkit in existence will 
add such a feature, because log spamming makes it harder for the administrator 
to find more important messages, and even if the administrator uses grep 
judiciously to filter them out, that doesn't help if logrotate has already 
deleted the log containing the information they need to keep /var/log from 
filling up.

>>> anymore. as soon as administrator gets this message, he can take
>>> action against that user (may be block user's access on server). i
>>> think the my fork patch is very useful and helps administrator lot.

You still haven't explained why this can't be done in userspace.  If forkbombing 
is a serious threat (and it's not) you can run a forkbomb monitor with realtime 
priority that won't be severely impacted by thrashing among normal priority 
processes.  Userspace has room for much more sophisticated processing anyway, so 
doing this in the kernel doesn't make much sense.

>>>                 i would also like to mention that in some of the cases
>>> ulimit solution wont work. in that case fork bombing takes the machine
>>> and server needs a reboot. i am sure in that situation this printk
>>> statement helps administrator to know what has happened.

SysRq-t makes it quite obvious that the system has been forkbombed, allowing the 
administrator to lower ulimits if the box can't handle the load permitted by the 
default settings.  Sometimes SysRq is inconvenient due to lack of physical 
access, which is why I wrote hangwatch[1].

Hangwatch monitors /proc/loadavg and writes the specified set of SysRq triggers 
into /proc/sysrq-trigger when the specified load average is exceeded, with the 
specified frequency.  It doesn't require forks or dynamic memory allocation, so 
it works basically any time the box isn't locked up enough to trigger NMI 
watchdog, though realtime users may want to run it with chrt priority.  It's 
very simple, but it's proven so effective that there really hasn't been much 
need to develop it further since I initially wrote it a year ago.

Given how much we can already do in userspace, I don't really see a need to 
implement this in the kernel.  If you'd like me to add features to hangwatch, 
let's talk about that.  You can even fork it yourself, since it's GPL.

	-- Chris

[1] http://people.redhat.com/csnook/hangwatch/
-
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