linux-kernel - Re: Fork Bombing Patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46CDD98F.2020208@redhat.com>
Date:	Thu, 23 Aug 2007 15:01:35 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Krzysztof Halasa <khc@...waw.pl>
CC:	Anand Jahagirdar <anandjigar@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Fork Bombing Patch

Krzysztof Halasa wrote:
> Hi,
> 
> "Anand Jahagirdar" <anandjigar@...il.com> writes:
> 
>>    I am forwarding one more improved patch which i have modified as
>> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
>> i have added one more if block to check hard limit. how good it is?
> 
> Not very, still lacks "#ifdef CONFIG_something" and the required
> Kconfig change (or other runtime thing defaulting to "no printk").

Wrapping a single printk that's unrelated to debugging in an #ifdef 
CONFIG_* or a sysctl strikes me as abuse of those configuration 
facilities.  Where would we draw the line for other patches wanting to 
do similar things?

I realized that even checking the hard limit it insufficient, because 
that can be lowered (but not raised) by unprivileged processes.  If we 
can't do this unconditionally (and we can't, because the log pollution 
would be intolerable for many people) then we shouldn't do it at all.

Anand -- I appreciate the effort, but I think you should reconsider 
precisely what problem you're trying to solve here.  This approach can't 
tell the difference between legitimate self-regulation of resource 
utilization and a real attack.  Worse, in the event of a real attack, it 
could be used to make it more difficult for the administrator to notice 
something much more serious than a forkbomb.

I suspect that userspace might be a better place to solve this problem. 
  You could run your monitoring app with elevated or even realtime 
priority to ensure it will still function, and you have much more 
freedom in making the reporting configurable.  You can also look at much 
more data than we could ever allow in fork.c, and possibly detect 
attacks that this patch would miss if a clever attacker stayed just 
below the limit.

	-- Chris
-
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/