Natanael Copa napisał(a):
> On Thu, 2005-03-31 at 12:11 -0500, Lee Revell wrote:
>
>
>>Didn't you ever look up what a ulimit is?
>
>
> ofcourse i did. I just think that ulimit (or other userspace tools)
> should be used to *raise* the limit if you need more. Not the reverse.
>
>
>>If you cons
On Thu, 2005-03-31 at 12:11 -0500, Lee Revell wrote:
> Didn't you ever look up what a ulimit is?
ofcourse i did. I just think that ulimit (or other userspace tools)
should be used to *raise* the limit if you need more. Not the reverse.
> If you consider your distro's default ulimits unreasonable
On Thu, 2005-03-31 at 12:00 +0200, Natanael Copa wrote:
> On Wed, 2005-03-30 at 19:40 +0200, Jacek Łuczak wrote:
> >
> > I made some tests and almost all Linux distros brings down while freebsd
> > survive!Forkbombing is a big problem but i don't think that something like
> I really liked this a
On Wed, 2005-03-30 at 19:40 +0200, Jacek Łuczak wrote:
> Hi
>
> I made some tests and almost all Linux distros brings down while freebsd
> survive!Forkbombing is a big problem but i don't think that something like
>
> max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
>
> is good solution
Natanael Copa napisał(a):
On Thu, 2005-03-31 at 01:46 +0200, Felipe Alfaro Solana wrote:
On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
<[EMAIL PROTECTED]> wrote:
The memory limits aren't good enough either: if you set them low
enough that memory-forkbombs are unperilous for
RLIMIT_NPROC*RLIMI
On Thu, 2005-03-31 at 01:46 +0200, Felipe Alfaro Solana wrote:
> On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
> <[EMAIL PROTECTED]> wrote:
> > > The memory limits aren't good enough either: if you set them low
> > > enough that memory-forkbombs are unperilous for
> > > RLIMIT_NPROC*RLIMIT_DA
On Mon, 28 Mar 2005 19:28:20 +0200, Matthieu Castet
<[EMAIL PROTECTED]> wrote:
> > The memory limits aren't good enough either: if you set them low
> > enough that memory-forkbombs are unperilous for
> > RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
> > applications.
>
> yes, if you
Hi
I made some tests and almost all Linux distros brings down while freebsd
survive!Forkbombing is a big problem but i don't think that something like
max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
is good solution!!!
How about add max_user_threads to the kernel? It could be tunable via
On Mon, 2005-03-28 at 19:28 +0200, Matthieu Castet wrote:
> > The memory limits aren't good enough either: if you set them low
> > enough that memory-forkbombs are unperilous for
> > RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
> > applications.
>
> yes, if you want to run applicati
Please,
would you be so kind to stop debugging your fork-bombing tools with all
the list in CC ? I think that most of us are not interested in knowning
whether the cast is necessary or not before the malloc(). This is LKML,
not FBTML. There are lots of ways to locally DoS linux, you don't need
to
On Mar 28, 2005, at 9:39 PM, [EMAIL PROTECTED] wrote:
On Mar 28, 2005, at 9:39 PM, [EMAIL PROTECTED] wrote:
I already posted one, posts ago.
[snip]
Imporved version:
[snip]
char *dummy = (char *)malloc(1);
That cast is not supposed to be there, is it? (To pretake it: it's
bad.)
What is so bad abou
> I already posted one, posts ago.
> >>[snip]
> >Imporved version:
> >[snip]
> >char *dummy = (char *)malloc(1);
> That cast is not supposed to be there, is it? (To pretake it: it's bad.)
What is so bad about it?
Folkert van Heusden
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkh
>> I think per user limit could be a solution.
>> attached a small fork-memory bombing.
I already posted one, posts ago.
>>[snip]
>Imporved version:
>[snip]
>char *dummy = (char *)malloc(1);
That cast is not supposed to be there, is it? (To pretake it: it's bad.)
Jan Engelhardt
--
No TOFU fo
> > The memory limits aren't good enough either: if you set them low
> > enough that memory-forkbombs are unperilous for
> > RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
> > applications.
> yes, if you want to run application like openoffice.org you need at
> least 200Mo. If you want
> The memory limits aren't good enough either: if you set them low
> enough that memory-forkbombs are unperilous for
> RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
> applications.
yes, if you want to run application like openoffice.org you need at
least 200Mo. If you want that your
On Sat, 2005-03-26 at 10:37 +, Tux wrote:
> I'm confused, are hard limits to RLIMIT_NPROC imposed on services
> spawned by init before a user logs in?
There are no "hard" limits to RLIMIT_NPROC. However, on fork, childern
inherits the parents limits. Non-root users can not raise the limit,
jus
I'm confused, are hard limits to RLIMIT_NPROC imposed on services
spawned by init before a user logs in?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On Thu, 2005-03-24 at 08:07 +0100, Jan Engelhardt wrote:
> >> >brings down almost all linux distro's while other *nixes survives.
> >>
> >> Let's see if this can be confirmed.
> >
> >open/free/netbsd survives. I guess OSX does too.
>
> Confirmed. My OpenBSD install copes very well with forkbombs.
>> >brings down almost all linux distro's while other *nixes survives.
>>
>> Let's see if this can be confirmed.
>
>open/free/netbsd survives. I guess OSX does too.
Confirmed. My OpenBSD install copes very well with forkbombs.
However, I _was able_ to spawn a lot of shells by default.
The essence
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 bet
On Wed, 2005-03-23 at 14:38 -0500, Kyle Moffett wrote:
> On Mar 23, 2005, at 09:43, Jan Engelhardt wrote:
> >> brings down almost all linux distro's while other *nixes survives.
> >
> > Let's see if this can be confirmed.
>
> Here at my school we have the workstations running Debian testing. We
>
On Thu, 2005-03-24 at 03:44 +0900, aq wrote:
> On Wed, 23 Mar 2005 10:05:43 -0800, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > > int main() { while(1) { fork(); fork(); exit(); } }
> > > ...
> > > the above forkbomb will stop quickly
> >
> > Yep.
> >
> > Try this forkbomb:
> >
> > int main() {
On Mar 23, 2005, at 09:43, Jan Engelhardt wrote:
brings down almost all linux distro's while other *nixes survives.
Let's see if this can be confirmed.
Here at my school we have the workstations running Debian testing. We
have edited /etc/security/limits.conf to have a much more restrictive
startup
On Wed, 23 Mar 2005 10:05:43 -0800, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > int main() { while(1) { fork(); fork(); exit(); } }
> > ...
> > the above forkbomb will stop quickly
>
> Yep.
>
> Try this forkbomb:
>
> int main() { while(1) { if (!fork()) continue; if (!fork()) continue;
> exit
> int main() { while(1) { fork(); fork(); exit(); } }
> ...
> the above forkbomb will stop quickly
Yep.
Try this forkbomb:
int main() { while(1) { if (!fork()) continue; if (!fork()) continue; exit();
} }
--
I won't rest till it's the best ...
Programmer,
On Wed, 23 Mar 2005 14:54:18 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-03-23 at 22:04 +0900, aq wrote:
> > On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > > > > This is an example of a program in C my friends gave me that
> > > > > forkbombs.
>
On Wed, 2005-03-23 at 15:52 +0100, Max Kellermann wrote:
> You see, RLIMIT_CPU is worthless in its current implementation.
You are right. Limiting CPU is probably not a good solution anyway.
http://marc.theaimsgroup.com/?l=linux-kernel&m=105808941823955&w=2
--
Natanael Copa
-
To unsubscribe f
On Wed, 2005-03-23 at 15:43 +0100, Jan Engelhardt wrote:
> >brings down almost all linux distro's while other *nixes survives.
>
> Let's see if this can be confirmed.
open/free/netbsd survives. I guess OSX does too.
Gentoo (non-hardened), Red Hat, Mandrake, FC2 are vulnerable.
Debian stable sur
On 2005/03/23 15:44, Natanael Copa <[EMAIL PROTECTED]> wrote:
> Yes, but if
> RLIMIT_NPROC is per user and RLIMIT_CPU is per proc
>
> the theoretical CPU limit per user is RLIMIT_NPROC * RLIMIT_CPU. So if
> you half the RLIMIT_NPROC you will half the theoretical maximum CPU
> limit per user.
>
>
On Wed, 2005-03-23 at 15:27 +0100, Max Kellermann wrote:
> On 2005/03/23 15:23, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-03-23 at 14:53 +0100, Max Kellermann wrote:
> > > The number of processes is counted per user, but CPU time and memory
> > > consumption is counted per process.
>brings down almost all linux distro's while other *nixes survives.
Let's see if this can be confirmed.
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majo
On 2005/03/23 15:23, Natanael Copa <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-03-23 at 14:53 +0100, Max Kellermann wrote:
> > The number of processes is counted per user, but CPU time and memory
> > consumption is counted per process.
>
> So limiting maximum number of processes will automatically l
On Wed, 2005-03-23 at 14:53 +0100, Max Kellermann wrote:
> On 2005/03/22 12:49, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > What if the few procs that he may spawn also grab so much memory so
> > your machine disappears in swap-t(h)rashing?
>
> The number of processes is counted per user, but CP
Natanael Copa <[EMAIL PROTECTED]> writes:
> well, the problem here has that stupid fork bombs like:
>
> :() { :|:& };:
>
> brings down almost all linux distro's while other *nixes survives.
I have seen a SunFire machine with 4GB RAM running Solaris grind to a
complete halt from a fork bomb.
--
On Wed, 2005-03-23 at 14:45 +0100, Erik Mouw wrote:
> On Wed, Mar 23, 2005 at 01:37:38PM +0100, Natanael Copa wrote:
> > On Wed, 2005-03-23 at 19:56 +0900, aq wrote:
> > > > /etc/limits does a better job at stopping forkbombs.
> >
> > but does not limit processes that are started from the boot scr
On Wed, 2005-03-23 at 22:04 +0900, aq wrote:
> On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > > > 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
> >
On 2005/03/22 12:49, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> What if the few procs that he may spawn also grab so much memory so
> your machine disappears in swap-t(h)rashing?
The number of processes is counted per user, but CPU time and memory
consumption is counted per process.
Going around
On Wed, Mar 23, 2005 at 01:37:38PM +0100, Natanael Copa wrote:
> On Wed, 2005-03-23 at 19:56 +0900, aq wrote:
> > > /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 attack
>If so, forkbomb doesnt cause much problem like they said, since
>eventually it would be killed once it reach the limit of memory. the
>system will recover automatically after awhile.
I doubt that! Maybe OOM strikes one process out, but as already said, when
that happens, it makes room for furth
On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > > 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 i
On Wed, 2005-03-23 at 19:56 +0900, aq wrote:
> On Tue, 22 Mar 2005 07:50:25 -0500, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> 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
On Tue, 22 Mar 2005 07:50:25 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> On Tue, Mar 22, 2005 at 12:49:58PM +0100, Jan Engelhardt wrote:
> > >
> > >This will prevent it from exceeding the procs limits, but it will *not*
> > >completely stop it.
> >
> > What if the few procs that he may sp
Hi list!
(I'm new to this list so I'm sorry this mail has not correct thread id)
I have been following this forkbombing discussions and I would like to
point out a few things:
* When setting limits /etc/limits (or /etc/security/limits.conf) you
will prevent logged in users to fork too many proce
On Tue, Mar 22, 2005 at 12:49:58PM +0100, Jan Engelhardt wrote:
> >
> >This will prevent it from exceeding the procs limits, but it will *not*
> >completely stop it.
>
> What if the few procs that he may spawn also grab so much memory so your
> machine disappears in swap-t(h)rashing?
While I have
>
>This will prevent it from exceeding the procs limits, but it will *not*
>completely stop it.
What if the few procs that he may spawn also grab so much memory so your
machine disappears in swap-t(h)rashing?
>The only way to kill it off successfully is to killall
>-9 the script name repeatedly.
Alright, I noticed this article scared a few of my friends, so I decided to
figure out on my own a way to prevent fork bombing from completely disabling
my machine.
This is only one way to do this, and it's not particularly elegant, but it
gets the job done. If you want something more elegant, try
>>William> Sure enough, I created the following script and ran it as a
>>William> non-root user:
>>
>>William> #!/bin/bash $0 & $0 &
>>
>>There are two approaches to fixing this.
>> 1. Rate limit fork()
>> 2. Limit (per user) the number of processes allowed
>
>Had to try it out of curiosity, f
On Mon, 21 Mar 2005 14:27:55 +1100, Peter Chubb <[EMAIL PROTECTED]> wrote:
>> "William" == William Beebe <[EMAIL PROTECTED]> writes:
>
>William> Sure enough, I created the following script and ran it as a
>William> non-root user:
>
>William> #!/bin/bash $0 & $0 &
>
>There are two approaches to
Thanks. That's what I thought. Sorry for the annoyance.
On Sun, 20 Mar 2005 22:22:21 -0500, Dave Jones <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 20, 2005 at 10:06:57PM -0500, William Beebe wrote:
>
> > Is this really a kernel issue? Or is there a better way in userland to
> > stop this kind of
> "William" == William Beebe <[EMAIL PROTECTED]> writes:
William> Sure enough, I created the following script and ran it as a
William> non-root user:
William> #!/bin/bash $0 & $0 &
There are two approaches to fixing this.
1. Rate limit fork(). Unfortunately some legitimate usges do a lot
On Sun, Mar 20, 2005 at 10:06:57PM -0500, William Beebe wrote:
> Is this really a kernel issue? Or is there a better way in userland to
> stop this kind of crap?
man ulimit
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
The following quote is from the article "Linux Kernel Security, Again"
(http://www.securityfocus.com/columnists/308):
"Don't get me wrong. Linux doesn't suck. But I do believe that the
Linux kernel team (and some of the Linux distributions that are still
vulnerable to fork bombing) need to take pr
52 matches
Mail list logo
