Re: forkbombing Linux distributions

From: Natanael Copa
Date: Wed Mar 23 2005 - 16:00:55 EST


On Thu, 2005-03-24 at 02:05 +0900, aq wrote:

> I agree that make kernel more restrictive by default is a good approach.

Thank you! For a moment I thought I was the only human on this planet
who thought that.

Next question is where and how and what is an appropiate limit? I have
not heard any better suggestions than this:

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


(FYI: A few lines below the default RLIMIT_NPROC is calculated from
max_threads/2)

This would give default maximum number of processes from the amount of
low memory:

RAM RLIMIT_NPROC
64MiB 256
128MiB 512
256MiB 1024
512MiB 2048
1GiB 4096

That would be sufficent for the users to play their games, compile ther
stuff etc while it would protect everyone from that classic shell fork
bomb by default.

Actually, Alan Cox tried this in the 2.4.7-ac1 kernel
http://marc.theaimsgroup.com/?l=linux-kernel&m=99617009115570&w=2

but I have no idea why it was raised to the double afterwards.

--
Natanael Copa


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/