All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.