Patch related with Fork Bombing Atack

Patch related with Fork Bombing Atack

[Anand Jahagirdar]

[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]

Dear Sir
            I am forwarding one patch related with fork bombing attack.

 actually ulimit helps to prevent fork bombing attack.

        1)    when i searched for the code which actually prevents
fork bombing attack in kernel/fork.c file, it took lot of time to
search for the code.

        2)  when we set the ulimit in /etc/security/limits.conf file
for guest account and then try fork bombing attack using guest
account. ulimit prevents fork bombing attack but administrator/root
user wont come to know that somebody is trying fork bombing attack on
his machine.

Due to this two reasons i tried to create a patch which will solve
above mentioned problems.

1) Commented Code in my patch will Definitely Help Developer to get
the prevention code for Fork bombing Attack very easily.

2) Printk message in my patch will definitely help Administrator/Root
User to detect which particular user is trying fork bombing attack on
his machine by looking at /var/log/messages or dmesg . he can take
action against that particular user and kill his processes.

Regards,
Anand

[-- Attachment #2: fork.patch~ --]
[-- Type: application/octet-stream, Size: 937 bytes --]

Index: root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c
===================================================================
--- root.orig/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-05-31 16:46:22.000000000 +0530
+++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-05-31 16:53:02.000000000 +0530
@@ -956,13 +956,18 @@
 		goto fork_out;
 
 	retval = -EAGAIN;
-	
+
+	/*
+	 * Following code does not allow Non Root User to cross its process 
+	 * limit and it prevents Fork Bombing Attack.
+	 */	
 	if (atomic_read(&p->user->processes) >=
 			p->signal->rlim[RLIMIT_NPROC].rlim_cur) {
 		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
-				p->user != &root_user) 
+				p->user != &root_user) {
+			printk(KERN_CRIT"User with uid %d is crossing its Process limit\n",p->user->uid);
 			goto bad_fork_free;
-		
+		}
 	}
 
 	atomic_inc(&p->user->__count);

Re: Patch related with Fork Bombing Atack

[Jens Axboe]

On Thu, May 31 2007, Anand Jahagirdar wrote:
> 2) Printk message in my patch will definitely help Administrator/Root
> User to detect which particular user is trying fork bombing attack on
> his machine by looking at /var/log/messages or dmesg . he can take
> action against that particular user and kill his processes.

You just opened a DoS possibility for any user, they can now flood the
syslog instead.

-- 
Jens Axboe

Re: Patch related with Fork Bombing Atack

[Anand Jahagirdar]

On 5/31/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Thu, May 31 2007, Anand Jahagirdar wrote:
> > 2) Printk message in my patch will definitely help Administrator/Root
> > User to detect which particular user is trying fork bombing attack on
> > his machine by looking at /var/log/messages or dmesg . he can take
> > action against that particular user and kill his processes.
>
> You just opened a DoS possibility for any user, they can now flood the
> syslog instead.
>
Jens Axboe

     when they try to flood the syslog using fork bombing attack,
their messge will be printed only once in syslog and it will show how
many times it has repeated. due to this he will not able to flood the
syslog.and i am using only one single variable in my printk messge so
it is quite not possible to flood the syslog.

   am i missing something??

anand
> --
>
>
>

Re: Patch related with Fork Bombing Atack

[Daniel Hazelton]

On Friday 01 June 2007 02:48:59 Anand Jahagirdar wrote:
> On 5/31/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> > On Thu, May 31 2007, Anand Jahagirdar wrote:
> > > 2) Printk message in my patch will definitely help Administrator/Root
> > > User to detect which particular user is trying fork bombing attack on
> > > his machine by looking at /var/log/messages or dmesg . he can take
> > > action against that particular user and kill his processes.
> >
> > You just opened a DoS possibility for any user, they can now flood the
> > syslog instead.
>
> Jens Axboe
>
>      when they try to flood the syslog using fork bombing attack,
> their messge will be printed only once in syslog and it will show how
> many times it has repeated. due to this he will not able to flood the
> syslog.and i am using only one single variable in my printk messge so
> it is quite not possible to flood the syslog.
>
>    am i missing something??
>
> anand

Most definately. Each printk() call outputs to syslog - which means that every 
time your code outputs its message there is another line in the logs. It then 
becomes possible to use that to flood the syslog.

DRH

(I hate having to explain the obvious)

Re: Patch related with Fork Bombing Atack

[Jens Axboe]

On Fri, Jun 01 2007, Daniel Hazelton wrote:
> On Friday 01 June 2007 02:48:59 Anand Jahagirdar wrote:
> > On 5/31/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > On Thu, May 31 2007, Anand Jahagirdar wrote:
> > > > 2) Printk message in my patch will definitely help Administrator/Root
> > > > User to detect which particular user is trying fork bombing attack on
> > > > his machine by looking at /var/log/messages or dmesg . he can take
> > > > action against that particular user and kill his processes.
> > >
> > > You just opened a DoS possibility for any user, they can now flood the
> > > syslog instead.
> >
> > Jens Axboe
> >
> >      when they try to flood the syslog using fork bombing attack,
> > their messge will be printed only once in syslog and it will show how
> > many times it has repeated. due to this he will not able to flood the
> > syslog.and i am using only one single variable in my printk messge so
> > it is quite not possible to flood the syslog.
> >
> >    am i missing something??
> >
> > anand
> 
> Most definately. Each printk() call outputs to syslog - which means
> that every time your code outputs its message there is another line in
> the logs. It then becomes possible to use that to flood the syslog.

I think Anand is assuming that because syslog may coalesce identical
messages into "repeated foo times" in the messages file, that it's not a
dos. That is of course wrong.

-- 
Jens Axboe

Re: Patch related with Fork Bombing Atack

[Daniel Hazelton]

On Friday 01 June 2007 03:30:20 Jens Axboe wrote:
> On Fri, Jun 01 2007, Daniel Hazelton wrote:
> > On Friday 01 June 2007 02:48:59 Anand Jahagirdar wrote:
> > > On 5/31/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > On Thu, May 31 2007, Anand Jahagirdar wrote:
> > > > > 2) Printk message in my patch will definitely help
> > > > > Administrator/Root User to detect which particular user is trying
> > > > > fork bombing attack on his machine by looking at /var/log/messages
> > > > > or dmesg . he can take action against that particular user and kill
> > > > > his processes.
> > > >
> > > > You just opened a DoS possibility for any user, they can now flood
> > > > the syslog instead.
> > >
> > > Jens Axboe
> > >
> > >      when they try to flood the syslog using fork bombing attack,
> > > their messge will be printed only once in syslog and it will show how
> > > many times it has repeated. due to this he will not able to flood the
> > > syslog.and i am using only one single variable in my printk messge so
> > > it is quite not possible to flood the syslog.
> > >
> > >    am i missing something??
> > >
> > > anand
> >
> > Most definately. Each printk() call outputs to syslog - which means
> > that every time your code outputs its message there is another line in
> > the logs. It then becomes possible to use that to flood the syslog.
>
> I think Anand is assuming that because syslog may coalesce identical
> messages into "repeated foo times" in the messages file, that it's not a
> dos. That is of course wrong.

Well... The problem, IMHO, isn't the logfiles flood-filling the disc but the 
klogd -> syslogd communications sucking down processor bandwidth and memory. 
A quick grep of the sources shows that the kernel doesn't do that 
nifty "repeated foo times" bit, but the userspace syslogd. That's what that 
closing tagline in my previous response to this thread was all about - the 
whole fact that the "repeated foo times" thing is from the userspace 
component of the syslog system. Any program fed the massive amount of input 
starting a recursive forkbomb would generate with the kernel doing this "I've 
detected a forkbomb" printk would start to lag as it struggled to keep up - 
so it starts using more and more processor until its stopped the machine from 
doing anything *but* process those messages. (Oh, wait - I just described the 
DoS that happens when the syslog gets flooded - silly me!)

DRH
PS: Most of that is for one persons benefit - hope I didn't offend anyone and 
that you've all enjoyed my attempt at sarcasm.

Re: Patch related with Fork Bombing Atack

[Jens Axboe]

On Fri, Jun 01 2007, Daniel Hazelton wrote:
> On Friday 01 June 2007 03:30:20 Jens Axboe wrote:
> > On Fri, Jun 01 2007, Daniel Hazelton wrote:
> > > On Friday 01 June 2007 02:48:59 Anand Jahagirdar wrote:
> > > > On 5/31/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > > On Thu, May 31 2007, Anand Jahagirdar wrote:
> > > > > > 2) Printk message in my patch will definitely help
> > > > > > Administrator/Root User to detect which particular user is trying
> > > > > > fork bombing attack on his machine by looking at /var/log/messages
> > > > > > or dmesg . he can take action against that particular user and kill
> > > > > > his processes.
> > > > >
> > > > > You just opened a DoS possibility for any user, they can now flood
> > > > > the syslog instead.
> > > >
> > > > Jens Axboe
> > > >
> > > >      when they try to flood the syslog using fork bombing attack,
> > > > their messge will be printed only once in syslog and it will show how
> > > > many times it has repeated. due to this he will not able to flood the
> > > > syslog.and i am using only one single variable in my printk messge so
> > > > it is quite not possible to flood the syslog.
> > > >
> > > >    am i missing something??
> > > >
> > > > anand
> > >
> > > Most definately. Each printk() call outputs to syslog - which means
> > > that every time your code outputs its message there is another line in
> > > the logs. It then becomes possible to use that to flood the syslog.
> >
> > I think Anand is assuming that because syslog may coalesce identical
> > messages into "repeated foo times" in the messages file, that it's not a
> > dos. That is of course wrong.
> 
> Well... The problem, IMHO, isn't the logfiles flood-filling the disc
> but the klogd -> syslogd communications sucking down processor
> bandwidth and memory.  A quick grep of the sources shows that the
> kernel doesn't do that nifty "repeated foo times" bit, but the
> userspace syslogd. That's what that closing tagline in my previous
> response to this thread was all about - the whole fact that the
> "repeated foo times" thing is from the userspace component of the
> syslog system. Any program fed the massive amount of input starting a
> recursive forkbomb would generate with the kernel doing this "I've
> detected a forkbomb" printk would start to lag as it struggled to keep
> up - so it starts using more and more processor until its stopped the
> machine from doing anything *but* process those messages. (Oh, wait -
> I just described the DoS that happens when the syslog gets flooded -
> silly me!)

Yep, otherwise there would be no need to have introduced
printk_ratelimit().

-- 
Jens Axboe

Re: Patch related with Fork Bombing Atack

[Nix]

On 1 Jun 2007, Jens Axboe told this:
> I think Anand is assuming that because syslog may coalesce identical
> messages into "repeated foo times" in the messages file, that it's not a
> dos. That is of course wrong.

Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.)

-- 
`On a scale of one to ten of usefulness, BBC BASIC was several points ahead
 of the competition, scoring a relatively respectable zero.' --- Peter Corlett

Re: Patch related with Fork Bombing Atack

[Daniel Hazelton]

On Sunday 03 June 2007 19:01:21 Nix wrote:
> On 1 Jun 2007, Jens Axboe told this:
> > I think Anand is assuming that because syslog may coalesce identical
> > messages into "repeated foo times" in the messages file, that it's not a
> > dos. That is of course wrong.
>
> Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.)

That syslog-ng doesn't coalesce repeated messages into a single line doesn't 
make a difference. The printk_ratelimit stuff is supposed to make it very 
hard to DOS a system by flooding syslog, but that doesn't mean its 
impossible. 

The point of this discussion was that having a part of the kernel log a 
message about a fork-bomb was a very large whole that could be used to DOS a 
system by flooding the syslog. (In fact, IIRC, the printk_ratelimit (and 
somebody, please correct me if I'm wrong) stuff uses a ring buffer and 
seriously spamming syslog, like the patch that spawned this thread would have 
done, could cause you to lose potentially important messages)

DRH

Re: Patch related with Fork Bombing Atack

[Anand Jahagirdar]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Hello All
            I am forwarding one improved patch related with Fork
Bombing Attack. This patch prints a message (only once) which alerts
administrator/root user about fork bombing attack. I created this
patch to implement my idea of informing administrator about fork
bombing attack on his machine only once.
    This patch overcomes all drawbacks of my previous patch related
with fork bombing attack and helps administrator. added comments will
definitely help developers.

Regards
Anand


On 6/3/07, Daniel Hazelton <dhazelton@enter.net> wrote:
> On Sunday 03 June 2007 19:01:21 Nix wrote:
> > On 1 Jun 2007, Jens Axboe told this:
> > > I think Anand is assuming that because syslog may coalesce identical
> > > messages into "repeated foo times" in the messages file, that it's not a
> > > dos. That is of course wrong.
> >
> > Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.)
>
> That syslog-ng doesn't coalesce repeated messages into a single line doesn't
> make a difference. The printk_ratelimit stuff is supposed to make it very
> hard to DOS a system by flooding syslog, but that doesn't mean its
> impossible.
>
> The point of this discussion was that having a part of the kernel log a
> message about a fork-bomb was a very large whole that could be used to DOS a
> system by flooding the syslog. (In fact, IIRC, the printk_ratelimit (and
> somebody, please correct me if I'm wrong) stuff uses a ring buffer and
> seriously spamming syslog, like the patch that spawned this thread would have
> done, could cause you to lose potentially important messages)
>
> DRH
>

[-- Attachment #2: fork.patch --]
[-- Type: application/octet-stream, Size: 1217 bytes --]

Index: root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c
===================================================================
--- root.orig/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-04 17:46:03.000000000 +0530
+++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-04 17:47:14.000000000 +0530
@@ -957,7 +957,19 @@
 
 	retval = -EAGAIN;
 	
+	/*
+	 * following code prints a message which alerts administrator/root 		 * user about fork bombing Attack
+	 */
+	if ((atomic_read(&p->user->processes) >= (p->signal->rlim	[RLIMIT_NPROC].rlim_cur - 1)) && (atomic_read(&p->user->processes) < p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {
+        	if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) && p->user != &root_user) {
+        		printk(KERN_CRIT"User with uid %d is crossing its Process limit\n",p->user->uid);
+        	}
+	}
 
+	/*
+	 * following code does not allow Non Root User to cross its process 
+	 * limit and it prevents Fork Bombing Attack.
+	 */
 	if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_cur) 
 		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
 				p->user != &root_user) 

Re: Patch related with Fork Bombing Atack

[Jiri Kosina]

On Mon, 4 Jun 2007, Anand Jahagirdar wrote:

>            I am forwarding one improved patch related with Fork Bombing 
> Attack. This patch prints a message (only once) which alerts 
> administrator/root user about fork bombing attack. I created this patch 
> to implement my idea of informing administrator about fork bombing 
> attack on his machine only once.
>    This patch overcomes all drawbacks of my previous patch related with 
> fork bombing attack and helps administrator. added comments will 
> definitely help developers.

> +	/*
> +	 * following code prints a message which alerts administrator/root 		 * user about fork bombing Attack
> +	 */
> +	if ((atomic_read(&p->user->processes) >= (p->signal->rlim	[RLIMIT_NPROC].rlim_cur - 1)) && (atomic_read(&p->user->processes) < p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {

Did this get malformed somehow? Looks like some successive lines got 
pasted together, or something.

> +        	if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) && p->user != &root_user) {
> +        		printk(KERN_CRIT"User with uid %d is crossing its Process limit\n",p->user->uid);
> +        	}
> +	}

Why not printk_ratelimit() here? Otherwise we have looped back to the 
possibility of user flooding the system logs, which has been already 
discussed in this thread, right? 

Also the { and } braces seem redundant.

Thanks,

-- 
Jiri Kosina

Re: Patch related with Fork Bombing Atack

[Daniel Hazelton]

On Monday 04 June 2007 10:58:41 Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
> >            I am forwarding one improved patch related with Fork Bombing
> > Attack. This patch prints a message (only once) which alerts
> > administrator/root user about fork bombing attack. I created this patch
> > to implement my idea of informing administrator about fork bombing
> > attack on his machine only once.
> >    This patch overcomes all drawbacks of my previous patch related with
> > fork bombing attack and helps administrator. added comments will
> > definitely help developers.
> >
> > +	/*
> > +	 * following code prints a message which alerts administrator/root 		 *
> > user about fork bombing Attack +	 */
> > +	if ((atomic_read(&p->user->processes) >=
> > (p->signal->rlim	[RLIMIT_NPROC].rlim_cur - 1)) &&
> > (atomic_read(&p->user->processes) <
> > p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {
>
> Did this get malformed somehow? Looks like some successive lines got
> pasted together, or something.

Seeing the lack of the '+' I think it's a mangling from not paying attention 
to the 80 column marker in the editor.

> > +        	if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
> > p->user != &root_user) { +        		printk(KERN_CRIT"User with uid %d is
> > crossing its Process limit\n",p->user->uid); +        	}
> > +	}
>
> Why not printk_ratelimit() here? Otherwise we have looped back to the
> possibility of user flooding the system logs, which has been already
> discussed in this thread, right?
>
> Also the { and } braces seem redundant.
They are. 

Here's two hints:
1) double check for hidden "word wrap" problems. A sane programmers editor 
will alert you to this, and careful checking of the patches before posting 
will also reveal them. (emacs shows a \ in the 80th column, jed puts a $ 
there, etc...)
2) when there is a potential for syslog spam - like your patch has - use 
printk_ratelimit() instead of printk(). This will throttle the output so that 
flooding the syslog is no longer possible.

DRH
ps: you patch is very difficult to apply - try using git

Re: Patch related with Fork Bombing Atack

[Anand Jahagirdar]

[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

Hello All
            I am forwarding one more improved patch related with fork
bombing attack. I have used printk_ratelimit function in my patch
and it works rellly well. it prints message as per printk_ratelimit
values stored in /proc/sys/kernel/printk_ratelimit
and /proc/sys/kernel/printk_ratelimit_burst.
root can set printk_ratelimit values(such as how many times message
should be repeated ,after how much time message should repeat) by
making changes in the above 2 mentioned files.
       this patch will never flood syslog anymore and will definitely
help administrator by informing him about fork bombing attack.
        added comments will help developers.

Regards,
Anand

On 6/4/07, Daniel Hazelton <dhazelton@enter.net> wrote:
> On Monday 04 June 2007 10:58:41 Jiri Kosina wrote:
> > On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
> > >            I am forwarding one improved patch related with Fork Bombing
> > > Attack. This patch prints a message (only once) which alerts
> > > administrator/root user about fork bombing attack. I created this patch
> > > to implement my idea of informing administrator about fork bombing
> > > attack on his machine only once.
> > >    This patch overcomes all drawbacks of my previous patch related with
> > > fork bombing attack and helps administrator. added comments will
> > > definitely help developers.
> > >
> > > +   /*
> > > +    * following code prints a message which alerts administrator/root               *
> > > user about fork bombing Attack +     */
> > > +   if ((atomic_read(&p->user->processes) >=
> > > (p->signal->rlim    [RLIMIT_NPROC].rlim_cur - 1)) &&
> > > (atomic_read(&p->user->processes) <
> > > p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {
> >
> > Did this get malformed somehow? Looks like some successive lines got
> > pasted together, or something.
>
> Seeing the lack of the '+' I think it's a mangling from not paying attention
> to the 80 column marker in the editor.
>
> > > +           if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
> > > p->user != &root_user) { +                  printk(KERN_CRIT"User with uid %d is
> > > crossing its Process limit\n",p->user->uid); +              }
> > > +   }
> >
> > Why not printk_ratelimit() here? Otherwise we have looped back to the
> > possibility of user flooding the system logs, which has been already
> > discussed in this thread, right?
> >
> > Also the { and } braces seem redundant.
> They are.
>
> Here's two hints:
> 1) double check for hidden "word wrap" problems. A sane programmers editor
> will alert you to this, and careful checking of the patches before posting
> will also reveal them. (emacs shows a \ in the 80th column, jed puts a $
> there, etc...)
> 2) when there is a potential for syslog spam - like your patch has - use
> printk_ratelimit() instead of printk(). This will throttle the output so that
> flooding the syslog is no longer possible.
>
> DRH
> ps: you patch is very difficult to apply - try using git
>

[-- Attachment #2: fork.patch --]
[-- Type: text/plain, Size: 1032 bytes --]

Index: root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c
===================================================================
--- root.orig/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-05 19:16:28.000000000 +0530
+++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-05 19:18:07.000000000 +0530
@@ -958,11 +958,18 @@
 	retval = -EAGAIN;
 	
 
+	/*
+         * following code does not allow Non Root User to cross its process
+         * limit. it alerts administrator about fork bombing attack and prevents
+         * it.
+         */
 	if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_cur) 
 		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
-				p->user != &root_user) 
-	
+				p->user != &root_user) {
+			if (printk_ratelimit())
+                                printk(KERN_CRIT"User with uid %d is crossing its process limit\n",p->user->uid);
 			goto bad_fork_free;
+		}
 				
 
 	atomic_inc(&p->user->__count);

Re: Patch related with Fork Bombing Atack

[Jiri Kosina]

On Fri, 1 Jun 2007, Anand Jahagirdar wrote:

>     when they try to flood the syslog using fork bombing attack, their 
> messge will be printed only once in syslog and it will show how many 
> times it has repeated. due to this he will not able to flood the 
> syslog.and i am using only one single variable in my printk messge so it 
> is quite not possible to flood the syslog.

Your argument is flawed - if the kernel provides more than one possibility 
to flood the syslogd, the is free to invoke the events interleaved. This 
trivially prevents syslogd from grouping identical reports together.

-- 
Jiri Kosina

Re: Patch related with Fork Bombing Atack

[Anand Jahagirdar]

Hello All

                I totally agree with all of you, but my idea behind
this patch is that administrator/root user must be able to know that
there is fork bombing attack on his machine and he should be able take
action agianst that particular user and kill all his processes.

can anybody please tell me how can we achive this??

Regards
Anand

On 6/1/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Fri, 1 Jun 2007, Anand Jahagirdar wrote:
>
> >     when they try to flood the syslog using fork bombing attack, their
> > messge will be printed only once in syslog and it will show how many
> > times it has repeated. due to this he will not able to flood the
> > syslog.and i am using only one single variable in my printk messge so it
> > is quite not possible to flood the syslog.
>
> Your argument is flawed - if the kernel provides more than one possibility
> to flood the syslogd, the is free to invoke the events interleaved. This
> trivially prevents syslogd from grouping identical reports together.
>
> --
> Jiri Kosina
>