public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



  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