From: Natanael Copa <mlists@tanael.org>
To: aq <aquynh@gmail.com>
Cc: "Hikaru1@verizon.net" <Hikaru1@verizon.net>,
linux-kernel@vger.kernel.org
Subject: Re: forkbombing Linux distributions
Date: Wed, 23 Mar 2005 13:37:38 +0100 [thread overview]
Message-ID: <1111581459.27969.36.camel@nc> (raw)
In-Reply-To: <9cde8bff050323025663637241@mail.gmail.com>
On Wed, 2005-03-23 at 19:56 +0900, aq wrote:
> On Tue, 22 Mar 2005 07:50:25 -0500, Hikaru1@verizon.net
> <Hikaru1@verizon.net> wrote:
> > While I have figured out how it'd be possible in theory to prevent things
> > from grabbing so much memory that your computer enters swap death, I haven't
> > been able to figure out what reasonable defaults would be for myself or
> > others. Soooo, I suggest everyone who is worried about this check the
> > manpage for 'limits' which tells you how to do this. My machine runs various
> > rediculously large and small programs - I'm not sure a forkbomb could be
> > stopped without hindering the usage of some of the games on my desktop
> > machine.
See patch below.
> > /etc/limits does a better job at stopping forkbombs.
but does not limit processes that are started from the boot scripts. So
if a buggy non-root service is exploited, an attacker would be able to
easily shut down the system.
> > This is an example of a program in C my friends gave me that forkbombs.
> > My previous sysctl.conf hack can't stop this, but the /etc/limits solution
> > enables the owner of the computer to do something about it as root.
> >
> > int main() { while(1) { fork(); } }
I guess that "fork twice and exit" is worse than this?
> I find that this forkbomb doesnt always kill the machine. Trying a
> small forkbomb, I saw that either the forkbomb process, or the parent
> process (of forkbomb) will be killed after a while (by the kernel)
> because of "out of memory" error. The problem is that which process
> would be chosen to kill? (I have no idea on how kernel choose the
> would-be-kill process).
It kills the process that reaches the limit (max proc's / out of mem)?
> If the kernel choose to kill the parent process, or the forkbomb
> itself, damage can be afford. Otherwise, if the more important
> processes are killed (like kernel threads or other daemons), things
> would be much more serious.
>
> Any idea?
Limit the default maximum of user processes. If someone needs more, let
the sysadmin raise it (with ulimit -u, /etc/limits, sysctl.conf
whatever)
This should do the trick:
--- kernel/fork.c.orig 2005-03-02 08:37:48.000000000 +0100
+++ kernel/fork.c 2005-03-21 15:22:50.000000000 +0100
@@ -119,7 +119,7 @@
* value: the thread structures can take up at most half
* of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
/*
* we need to allow at least 20 threads to boot a system
--
Natanael Copa
next prev parent reply other threads:[~2005-03-23 12:38 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-21 3:06 forkbombing Linux distributions William Beebe
2005-03-21 3:22 ` Dave Jones
2005-03-21 3:26 ` William Beebe
2005-03-21 3:27 ` Peter Chubb
2005-03-21 5:14 ` Grant Coady
2005-03-21 7:41 ` Jan Engelhardt
2005-03-22 11:26 ` Hikaru1
2005-03-22 11:49 ` Jan Engelhardt
[not found] ` <20050322124812.GB18256@roll>
2005-03-22 12:50 ` Hikaru1
2005-03-23 10:56 ` aq
2005-03-23 12:37 ` Natanael Copa [this message]
2005-03-23 13:04 ` aq
2005-03-23 13:38 ` Jan Engelhardt
2005-03-23 13:54 ` Natanael Copa
2005-03-23 14:20 ` Måns Rullgård
2005-03-23 14:43 ` Jan Engelhardt
2005-03-23 15:04 ` Natanael Copa
2005-03-24 7:07 ` Jan Engelhardt
2005-03-24 10:05 ` Natanael Copa
2005-03-23 19:38 ` Kyle Moffett
2005-03-23 20:26 ` Natanael Copa
2005-03-23 17:05 ` aq
2005-03-23 18:05 ` Paul Jackson
2005-03-23 18:44 ` aq
2005-03-23 20:15 ` Natanael Copa
2005-03-23 20:48 ` Natanael Copa
2005-03-23 13:45 ` Erik Mouw
2005-03-23 14:03 ` Natanael Copa
2005-03-23 13:53 ` Max Kellermann
2005-03-23 14:23 ` Natanael Copa
2005-03-23 14:27 ` Max Kellermann
2005-03-23 14:44 ` Natanael Copa
2005-03-23 14:52 ` Max Kellermann
2005-03-23 15:18 ` Natanael Copa
2005-03-26 10:37 ` Tux
2005-03-28 8:03 ` Natanael Copa
-- strict thread matches above, loose matches on Subject: below --
2005-03-22 17:09 Natanael Copa
2005-03-28 17:28 Matthieu Castet
2005-03-28 17:56 ` folkert
2005-03-28 19:33 ` Jan Engelhardt
2005-03-28 19:39 ` folkert
2005-03-28 20:35 ` Renate Meijer
2005-03-29 12:31 ` Natanael Copa
2005-03-30 23:46 ` Felipe Alfaro Solana
2005-03-31 6:55 ` Natanael Copa
2005-03-31 7:09 ` Jacek Łuczak
2005-03-30 17:40 Jacek Łuczak
2005-03-31 10:00 ` Natanael Copa
2005-03-31 17:11 ` Lee Revell
2005-04-05 9:47 ` Natanael Copa
2005-04-05 10:18 ` Jacek Luczak
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=1111581459.27969.36.camel@nc \
--to=mlists@tanael.org \
--cc=Hikaru1@verizon.net \
--cc=aquynh@gmail.com \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox