Fork Bombing Patch

Fork Bombing Patch

[Anand Jahagirdar]

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

Hello All
           I have searched for Maintainers List to get the correct
Maintainer for my patch. But i am not getting exact maintainer to
which i should forward my patch. Will any body please tell me,to which
maintainer i should forward my patch for its inclusion?

Summery of the Patch:

This patch Warns the administrator about the fork bombing attack
(whenever any user is crossing its process limit). I have used
printk_ratelimit function in this patch. This function helps to
prevent flooding of syslog and prints message as per the values set by
root user in following files:-

1) /proc/sys/kernel/printk_ratelimit:- This file contains value for,
how many times message should be printed in syslog.

2) /proc/sys/kernel/printk_ratelimit_burst: - This file contains value
for, after how much time message should be repeated.

This patch is really helpful for administrator/root user from security
point of view. They can take action against attacker by looking at
syslog messages related with fork bombing attack.

Added comments will definitely help developers.

Signed-Off-by: Anand Jahagirdar <anandjigar@gmail.com>

[-- Attachment #2: fork.patch~ --]
[-- Type: text/plain, Size: 1109 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-26 20:40:06.000000000 +0530
+++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:41:41.000000000 +0530
@@ -957,12 +957,19 @@
 
 	retval = -EAGAIN;
 	
-        
+        /*
+         * following code does not allow Non Root User to cross its process
+         * limit and it alerts administrator about user Nearing the process limit.
+         */
+ 
       	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_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
+
 			 goto bad_fork_free;
-			
+		}			
 			
 	atomic_inc(&p->user->__count);
 	atomic_inc(&p->user->processes);

Re: Fork Bombing Patch

[Petr Tesarik]

On Thu, 2007-08-16 at 11:54 +0530, Anand Jahagirdar wrote:
> Hello All
>            I have searched for Maintainers List to get the correct
> Maintainer for my patch. But i am not getting exact maintainer to
> which i should forward my patch. Will any body please tell me,to which
> maintainer i should forward my patch for its inclusion?
> 
> Summery of the Patch:
> 
> This patch Warns the administrator about the fork bombing attack
> (whenever any user is crossing its process limit). I have used
> printk_ratelimit function in this patch. This function helps to
> prevent flooding of syslog and prints message as per the values set by
> root user in following files:-
> 
> 1) /proc/sys/kernel/printk_ratelimit:- This file contains value for,
> how many times message should be printed in syslog.
> 
> 2) /proc/sys/kernel/printk_ratelimit_burst: - This file contains value
> for, after how much time message should be repeated.
> 
> This patch is really helpful for administrator/root user from security
> point of view. They can take action against attacker by looking at
> syslog messages related with fork bombing attack.
> 
> Added comments will definitely help developers.
> 
> Signed-Off-by: Anand Jahagirdar <anandjigar@gmail.com>
> 
> 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-26 20:40:06.000000000 +0530
> +++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:41:41.000000000 +0530
> @@ -957,12 +957,19 @@
>  
>  	retval = -EAGAIN;
>  	
> -        
> +        /*
> +         * following code does not allow Non Root User to cross its process
> +         * limit and it alerts administrator about user Nearing the process limit.
> +         */
> + 

Please do not add comments inside functions. The printk() is self-descriptive, anyway.

>        	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_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
> +
>  			 goto bad_fork_free;
> -			
> +		}			
>  			
>  	atomic_inc(&p->user->__count);
>  	atomic_inc(&p->user->processes);

Re: Fork Bombing Patch

[Krzysztof Halasa]

"Anand Jahagirdar" <anandjigar@gmail.com> writes:

> +++ linux-2.6.17/kernel/fork.c
> +        /*
> +         * following code does not allow Non Root User to cross its process
> +         * limit and it alerts administrator about user Nearing the process limit.
> +         */
> + 
>        	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_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
> +
>  			 goto bad_fork_free;

At least make that configurable - on some systems users are allowed
50 processes or so and I'm sure admins don't really want to know
which particular users are currently close to limits.

I don't really find the above useful. Perhaps we should warn when users
try to write to R/O files or execute root-only commands etc?
-- 
Krzysztof Halasa

Re: Fork Bombing Patch

[Jan Engelhardt]

On Aug 16 2007 13:19, Krzysztof Halasa wrote:
>
>At least make that configurable - on some systems users are allowed
>50 processes or so and I'm sure admins don't really want to know
>which particular users are currently close to limits.
>
>I don't really find the above useful. Perhaps we should warn when users
>try to write to R/O files or execute root-only commands etc?

At least make that configurable.


	Jan
-- 

Re: Fork Bombing Patch

[Chris Snook]

Anand Jahagirdar wrote:
> Hello All
>            I have searched for Maintainers List to get the correct
> Maintainer for my patch. But i am not getting exact maintainer to
> which i should forward my patch. Will any body please tell me,to which
> maintainer i should forward my patch for its inclusion?
> 
> Summery of the Patch:
> 
> This patch Warns the administrator about the fork bombing attack
> (whenever any user is crossing its process limit). I have used
> printk_ratelimit function in this patch. This function helps to
> prevent flooding of syslog and prints message as per the values set by
> root user in following files:-
> 
> 1) /proc/sys/kernel/printk_ratelimit:- This file contains value for,
> how many times message should be printed in syslog.
> 
> 2) /proc/sys/kernel/printk_ratelimit_burst: - This file contains value
> for, after how much time message should be repeated.
> 
> This patch is really helpful for administrator/root user from security
> point of view. They can take action against attacker by looking at
> syslog messages related with fork bombing attack.
> 
> Added comments will definitely help developers.
> 
> Signed-Off-by: Anand Jahagirdar <anandjigar@gmail.com>
> 
> 
> ------------------------------------------------------------------------
> 
> 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-26 20:40:06.000000000 +0530
> +++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:41:41.000000000 +0530
> @@ -957,12 +957,19 @@
>  
>  	retval = -EAGAIN;
>  	
> -        
> +        /*
> +         * following code does not allow Non Root User to cross its process
> +         * limit and it alerts administrator about user Nearing the process limit.
> +         */
> + 
>        	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_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
> +
>  			 goto bad_fork_free;
> -			
> +		}			
>  			
>  	atomic_inc(&p->user->__count);
>  	atomic_inc(&p->user->processes);

1) The printk is misleading.  We're hitting this condition because the 
user has hit the limit, not merely approached it.

2) This should probably be KERN_INFO.  The kernel itself is not in any 
danger because of this condition.

3) You should only be printing a warning if the user's hard limit is 
exceeded, not the soft limit.  While these default to the same value, 
applications are free to deliberately lower their soft limit to 
self-manage their resource utilization.  It's even perfectly valid (if 
uncommon) to lower the limit and deliberately keep your process count 
right at that limit by forking opportunistically.  If an application is 
doing this, you don't need or want to spam the message logs.  So, check 
to see if p->signal->rlim[RLIMIT_NPROC].rlim_cur == 
p->signal->rlim[RLIMIT_NPROC].rlim_max before spewing this out into the log.

4) Even with the printk_ratelimit, lowering the priority to KERN_INFO, 
and only logging when the hard limit is reached, an unprivileged user 
can still spam the system logs.  Perhaps a sysctl is in order?

	-- Chris

Re: Fork Bombing Patch

[Paul Jackson]

Petr wrote:
> Please do not add comments inside functions.

I find this advice a bit odd.  I am not aware of
any prohibition of comments inside functions.

As with comments outside functions, they should
serve a worthwhile purpose, of course.  One might
debate whether this particular comment added by
Anand was sufficiently valuable to be worth
having.

But I don't agree to a blanket prohibition on
comments inside functions.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Fork Bombing Patch

[Petr Tesarik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Jackson wrote:
> Petr wrote:
>> Please do not add comments inside functions.
> 
> I find this advice a bit odd.  I am not aware of
> any prohibition of comments inside functions.
> 
> As with comments outside functions, they should
> serve a worthwhile purpose, of course.  One might
> debate whether this particular comment added by
> Anand was sufficiently valuable to be worth
> having.
> 
> But I don't agree to a blanket prohibition on
> comments inside functions.

I'm not saying that comments inside functions should be prohibited, but
comments inside functions often lead to over-commenting. There must be a
good reason for adding such a comment. See CodingStyle, chapter 8:
Commenting:

Also, try to avoid putting comments inside a function body.

(Before somebody starts arguing with this one sentence, please also read
the rest of the chapter; it is not long and you'll understand the
author's intention better.)

Kind regards,
Petr Tesarik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxVFLjpY2ODFi2ogRAoLUAJwI+cywi9iKHWlx4yora0+WJfCEawCglyrf
xyucPIB3W63sbM1dw/Nsv2Y=
=SL8f
-----END PGP SIGNATURE-----

Re: Fork Bombing Patch

[Paul Jackson]

I agree that (1) one risks overdoing comments and (2) one should minimize
comments inside a function body.

But I read your earlier statement:

  Please do not add comments inside functions.

as simply requesting no comments inside function bodies, without
exception.  That seems to me to be too strong a statement.

The "try to avoid" in the CodingStyle I read as meaning roughly
"minimize" which is consistent with what it further states, allowing
for "small comments" in certain cases.

Admittedly, I probably agree with you that the command that Anand
added in his patch was one of those comments that didn't add enough
value to be justified.

I was just quibbling over the wording of your objections to it.

 ... I'll shut up now.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Fork Bombing Patch

[Anand Jahagirdar]

Hi
   As Per the Previous Discussion of my Patch,I think insted of using
KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
thats why i used KERN_WARNING.it will warn administrator and its
administrator responsibility to take whatever action he want to take.

anand

On 8/17/07, Chris Snook <csnook@redhat.com> wrote:
> Anand Jahagirdar wrote:
> > Hello All
> >            I have searched for Maintainers List to get the correct
> > Maintainer for my patch. But i am not getting exact maintainer to
> > which i should forward my patch. Will any body please tell me,to which
> > maintainer i should forward my patch for its inclusion?
> >
> > Summery of the Patch:
> >
> > This patch Warns the administrator about the fork bombing attack
> > (whenever any user is crossing its process limit). I have used
> > printk_ratelimit function in this patch. This function helps to
> > prevent flooding of syslog and prints message as per the values set by
> > root user in following files:-
> >
> > 1) /proc/sys/kernel/printk_ratelimit:- This file contains value for,
> > how many times message should be printed in syslog.
> >
> > 2) /proc/sys/kernel/printk_ratelimit_burst: - This file contains value
> > for, after how much time message should be repeated.
> >
> > This patch is really helpful for administrator/root user from security
> > point of view. They can take action against attacker by looking at
> > syslog messages related with fork bombing attack.
> >
> > Added comments will definitely help developers.
> >
> > Signed-Off-by: Anand Jahagirdar <anandjigar@gmail.com>
> >
> >
> > ------------------------------------------------------------------------
> >
> > 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-26 20:40:06.000000000 +0530
> > +++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c     2007-06-26 20:41:41.000000000 +0530
> > @@ -957,12 +957,19 @@
> >
> >       retval = -EAGAIN;
> >
> > -
> > +        /*
> > +         * following code does not allow Non Root User to cross its process
> > +         * limit and it alerts administrator about user Nearing the process limit.
> > +         */
> > +
> >               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_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
> > +
> >                        goto bad_fork_free;
> > -
> > +             }
> >
> >       atomic_inc(&p->user->__count);
> >       atomic_inc(&p->user->processes);
>
> 1) The printk is misleading.  We're hitting this condition because the
> user has hit the limit, not merely approached it.
>
> 2) This should probably be KERN_INFO.  The kernel itself is not in any
> danger because of this condition.
>
> 3) You should only be printing a warning if the user's hard limit is
> exceeded, not the soft limit.  While these default to the same value,
> applications are free to deliberately lower their soft limit to
> self-manage their resource utilization.  It's even perfectly valid (if
> uncommon) to lower the limit and deliberately keep your process count
> right at that limit by forking opportunistically.  If an application is
> doing this, you don't need or want to spam the message logs.  So, check
> to see if p->signal->rlim[RLIMIT_NPROC].rlim_cur ==
> p->signal->rlim[RLIMIT_NPROC].rlim_max before spewing this out into the log.
>
> 4) Even with the printk_ratelimit, lowering the priority to KERN_INFO,
> and only logging when the hard limit is reached, an unprivileged user
> can still spam the system logs.  Perhaps a sysctl is in order?
>
>        -- Chris
>

Re: Fork Bombing Patch

[Anand Jahagirdar]

Hi
  I think Its not worth to make it configurable just for one printk
statement. am i missing something?

anand

On 8/16/07, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> "Anand Jahagirdar" <anandjigar@gmail.com> writes:
>
> > +++ linux-2.6.17/kernel/fork.c
> > +        /*
> > +         * following code does not allow Non Root User to cross its process
> > +         * limit and it alerts administrator about user Nearing the process limit.
> > +         */
> > +
> >               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_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
> > +
> >                        goto bad_fork_free;
>
> At least make that configurable - on some systems users are allowed
> 50 processes or so and I'm sure admins don't really want to know
> which particular users are currently close to limits.
>
> I don't really find the above useful. Perhaps we should warn when users
> try to write to R/O files or execute root-only commands etc?
> --
> Krzysztof Halasa
>

Re: Fork Bombing Patch

[Jesper Juhl]

(please don't top-post)

On 20/08/07, Anand Jahagirdar <anandjigar@gmail.com> wrote:
> Hi
>   I think Its not worth to make it configurable just for one printk
> statement. am i missing something?
>

I think you are missing the fact that there are lots of situations
where users may hit the configured process limit without that being an
indication of a fork bomb (or other) attack.
This means that there will be many systems that will trigger your
warning where there really is no problem. That's a good reason for a)
making the message KERN_INFO and b) let administrators somehow disable
it completely.

Personally I'm wondering if we even want/need this at all.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Fork Bombing Patch

[Chris Snook]

Anand Jahagirdar wrote:
> Hi
>    As Per the Previous Discussion of my Patch,I think insted of using
> KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
> thats why i used KERN_WARNING.it will warn administrator and its
> administrator responsibility to take whatever action he want to take.
> 
> anand

Philosophically, I'm okay with the idea of a forkbomb meriting KERN_WARN 
priority, but we should never have a printk that can be trivially triggered by 
an unprivileged user that gets anything higher than KERN_INFO.  If I'm an 
attacker, and I want to do bad things without getting logged, the first thing I 
do is launch a carefully-tuned forkbomb that doesn't bog down the system, just 
triggers this message as often as the ratelimit will allow.  Once /var/log is 
full, I can do my nastiness.  Administrators need to be able to protect against 
that kind of thing without losing the ability to log KERN_WARN and higher 
priority messages.

Also, I stand by my assertion that we should only be complaining if the hard 
limit is also exceeded, since it's totally valid for an application to 
self-constrain using soft limits.  It may be uncommon, but the people who happen 
to use whatever applications do this will be very unhappy when they update their 
kernel and /var fills up from this spew.

	-- Chris

Re: Fork Bombing Patch

[Anand Jahagirdar]

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

Hi
   I am forwarding one more improved patch which i have modified as
per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
i have added one more if block to check hard limit. how good it is?

anand

On 8/20/07, Chris Snook <csnook@redhat.com> wrote:
> Anand Jahagirdar wrote:
> > Hi
> >    As Per the Previous Discussion of my Patch,I think insted of using
> > KERN_CRIT,it is better to lower the priority level to KERN_WARNING.
> > thats why i used KERN_WARNING.it will warn administrator and its
> > administrator responsibility to take whatever action he want to take.
> >
> > anand
>
> Philosophically, I'm okay with the idea of a forkbomb meriting KERN_WARN
> priority, but we should never have a printk that can be trivially triggered by
> an unprivileged user that gets anything higher than KERN_INFO.  If I'm an
> attacker, and I want to do bad things without getting logged, the first thing I
> do is launch a carefully-tuned forkbomb that doesn't bog down the system, just
> triggers this message as often as the ratelimit will allow.  Once /var/log is
> full, I can do my nastiness.  Administrators need to be able to protect against
> that kind of thing without losing the ability to log KERN_WARN and higher
> priority messages.
>
> Also, I stand by my assertion that we should only be complaining if the hard
> limit is also exceeded, since it's totally valid for an application to
> self-constrain using soft limits.  It may be uncommon, but the people who happen
> to use whatever applications do this will be very unhappy when they update their
> kernel and /var fills up from this spew.
>
>        -- Chris
>

[-- Attachment #2: fork.patch --]
[-- Type: application/octet-stream, Size: 1197 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-26 20:40:06.000000000 +0530
+++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:41:41.000000000 +0530
@@ -957,12 +957,19 @@
 
 	retval = -EAGAIN;
 	
-        
+        /*
+         * following code does not allow Non Root User to cross its process
+         * limit and it alerts administrator about user Nearing the process limit.
+         */
+ 
       	if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_cur) 
+		 if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_max)
	 		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
-				p->user != &root_user) 
+				p->user != &root_user)  {
+                        	if (printk_ratelimit())
+                               	 printk(KERN_NOTICE "User with uid %u is Nearing the process limit\n",p->user->uid);
+
 			 	goto bad_fork_free;
-			
+			}			
 			
 	atomic_inc(&p->user->__count);
 	atomic_inc(&p->user->processes);

Re: Fork Bombing Patch

[Krzysztof Halasa]

Hi,

"Anand Jahagirdar" <anandjigar@gmail.com> writes:

>    I am forwarding one more improved patch which i have modified as
> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
> i have added one more if block to check hard limit. how good it is?

Not very, still lacks "#ifdef CONFIG_something" and the required
Kconfig change (or other runtime thing defaulting to "no printk").

And now, it seems, the "goto bad_fork_tree" (not only printk())
ignores the soft limit -> really bad.

> +++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:41:41.000000000 +0530
> @@ -957,12 +957,19 @@
>  
>  	retval = -EAGAIN;
>  	
> -        
> +        /*
> +         * following code does not allow Non Root User to cross its process
> +         * limit and it alerts administrator about user Nearing the process limit.
> +         */
> + 
>        	if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_cur) 
> +		 if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_max)
> 	 		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
> -				p->user != &root_user) 
> +				p->user != &root_user)  {
> +                        	if (printk_ratelimit())
> +                               	 printk(KERN_NOTICE "User with uid %u is Nearing the process limit\n",p->user->uid);
> +
>  			 	goto bad_fork_free;
> -			
> +			}			
>  			
>  	atomic_inc(&p->user->__count);
>  	atomic_inc(&p->user->processes);

-- 
Krzysztof Halasa

Re: Fork Bombing Patch

[Chris Snook]

Krzysztof Halasa wrote:
> Hi,
> 
> "Anand Jahagirdar" <anandjigar@gmail.com> writes:
> 
>>    I am forwarding one more improved patch which i have modified as
>> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
>> i have added one more if block to check hard limit. how good it is?
> 
> Not very, still lacks "#ifdef CONFIG_something" and the required
> Kconfig change (or other runtime thing defaulting to "no printk").

Wrapping a single printk that's unrelated to debugging in an #ifdef 
CONFIG_* or a sysctl strikes me as abuse of those configuration 
facilities.  Where would we draw the line for other patches wanting to 
do similar things?

I realized that even checking the hard limit it insufficient, because 
that can be lowered (but not raised) by unprivileged processes.  If we 
can't do this unconditionally (and we can't, because the log pollution 
would be intolerable for many people) then we shouldn't do it at all.

Anand -- I appreciate the effort, but I think you should reconsider 
precisely what problem you're trying to solve here.  This approach can't 
tell the difference between legitimate self-regulation of resource 
utilization and a real attack.  Worse, in the event of a real attack, it 
could be used to make it more difficult for the administrator to notice 
something much more serious than a forkbomb.

I suspect that userspace might be a better place to solve this problem. 
  You could run your monitoring app with elevated or even realtime 
priority to ensure it will still function, and you have much more 
freedom in making the reporting configurable.  You can also look at much 
more data than we could ever allow in fork.c, and possibly detect 
attacks that this patch would miss if a clever attacker stayed just 
below the limit.

	-- Chris

Re: Fork Bombing Patch

[Krzysztof Halasa]

Chris Snook <csnook@redhat.com> writes:

> Wrapping a single printk that's unrelated to debugging in an #ifdef
> CONFIG_* or a sysctl strikes me as abuse of those configuration
> facilities.

Abuse, probably not (if a thing is required on one system and must
not be on another, it has to be configurable). If the printk is
a good idea... IMHO hardly, at best. We don't warn about trying to
write to /vmlinuz after all.

ulimit/pam_limits should fix the (IMHO nonexistent) problem nicely.
One has to plug all the holes, though (e.g. $HOME/.forward).
-- 
Krzysztof Halasa

Re: Fork Bombing Patch

[Tom Spink]

On 23/08/07, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Chris Snook <csnook@redhat.com> writes:
>
> > Wrapping a single printk that's unrelated to debugging in an #ifdef
> > CONFIG_* or a sysctl strikes me as abuse of those configuration
> > facilities.
>
> Abuse, probably not (if a thing is required on one system and must
> not be on another, it has to be configurable). If the printk is
> a good idea... IMHO hardly, at best. We don't warn about trying to
> write to /vmlinuz after all.
>
> ulimit/pam_limits should fix the (IMHO nonexistent) problem nicely.
> One has to plug all the holes, though (e.g. $HOME/.forward).
> --
> Krzysztof Halasa
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Hi,

I agree with Chris on this point, it seems like this sort of detection
(and reporting) should be a job for a user-space daemon, rather than
polluting kernel code (and logs) with warning messages of this sort...
I don't think the type of warning this patch yields is appropriate for
kernel logs, nor do I think the kernel should be the entity to decide
that this warning should be given.

It _feels_ wrong.

--
Regards,
Tom Spink
University of Edinburgh

Re: Fork Bombing Patch

[Anand Jahagirdar]

Hi
                printk_ratelimit function takes care of flooding the
syslog. due to printk_ratelimit function syslog will not be flooded
anymore. as soon as administrator gets this message, he can take
action against that user (may be block user's access on server). i
think the my fork patch is very useful and helps administrator lot.
                i would also like to mention that in some of the cases
ulimit solution wont work. in that case fork bombing takes the machine
and server needs a reboot. i am sure in that situation this printk
statement helps administrator to know what has happened.

Anand

On 8/24/07, Chris Snook <csnook@redhat.com> wrote:
> Krzysztof Halasa wrote:
> > Hi,
> >
> > "Anand Jahagirdar" <anandjigar@gmail.com> writes:
> >
> >>    I am forwarding one more improved patch which i have modified as
> >> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
> >> i have added one more if block to check hard limit. how good it is?
> >
> > Not very, still lacks "#ifdef CONFIG_something" and the required
> > Kconfig change (or other runtime thing defaulting to "no printk").
>
> Wrapping a single printk that's unrelated to debugging in an #ifdef
> CONFIG_* or a sysctl strikes me as abuse of those configuration
> facilities.  Where would we draw the line for other patches wanting to
> do similar things?
>
> I realized that even checking the hard limit it insufficient, because
> that can be lowered (but not raised) by unprivileged processes.  If we
> can't do this unconditionally (and we can't, because the log pollution
> would be intolerable for many people) then we shouldn't do it at all.
>
> Anand -- I appreciate the effort, but I think you should reconsider
> precisely what problem you're trying to solve here.  This approach can't
> tell the difference between legitimate self-regulation of resource
> utilization and a real attack.  Worse, in the event of a real attack, it
> could be used to make it more difficult for the administrator to notice
> something much more serious than a forkbomb.
>
> I suspect that userspace might be a better place to solve this problem.
>  You could run your monitoring app with elevated or even realtime
> priority to ensure it will still function, and you have much more
> freedom in making the reporting configurable.  You can also look at much
> more data than we could ever allow in fork.c, and possibly detect
> attacks that this patch would miss if a clever attacker stayed just
> below the limit.
>
>        -- Chris
>

Re: Fork Bombing Patch

[Simon Arlott]

On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
> Hi
>                 printk_ratelimit function takes care of flooding the
> syslog. due to printk_ratelimit function syslog will not be flooded
> anymore. as soon as administrator gets this message, he can take
> action against that user (may be block user's access on server). i
> think the my fork patch is very useful and helps administrator lot.
>                 i would also like to mention that in some of the cases
> ulimit solution wont work. in that case fork bombing takes the machine
> and server needs a reboot. i am sure in that situation this printk
> statement helps administrator to know what has happened.

If ulimit "wont work" in some situations, how is it going to trigger this printk?
(When doesn't it work?)

> Anand
>
> On 8/24/07, Chris Snook <csnook@redhat.com> wrote:
>> Krzysztof Halasa wrote:
>> > Hi,
>> >
>> > "Anand Jahagirdar" <anandjigar@gmail.com> writes:
>> >
>> >>    I am forwarding one more improved patch which i have modified as
>> >> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
>> >> i have added one more if block to check hard limit. how good it is?
>> >
>> > Not very, still lacks "#ifdef CONFIG_something" and the required
>> > Kconfig change (or other runtime thing defaulting to "no printk").
>>
>> Wrapping a single printk that's unrelated to debugging in an #ifdef
>> CONFIG_* or a sysctl strikes me as abuse of those configuration
>> facilities.  Where would we draw the line for other patches wanting to
>> do similar things?
>>
>> I realized that even checking the hard limit it insufficient, because
>> that can be lowered (but not raised) by unprivileged processes.  If we
>> can't do this unconditionally (and we can't, because the log pollution
>> would be intolerable for many people) then we shouldn't do it at all.
>>
>> Anand -- I appreciate the effort, but I think you should reconsider
>> precisely what problem you're trying to solve here.  This approach can't
>> tell the difference between legitimate self-regulation of resource
>> utilization and a real attack.  Worse, in the event of a real attack, it
>> could be used to make it more difficult for the administrator to notice
>> something much more serious than a forkbomb.
>>
>> I suspect that userspace might be a better place to solve this problem.
>>  You could run your monitoring app with elevated or even realtime
>> priority to ensure it will still function, and you have much more
>> freedom in making the reporting configurable.  You can also look at much
>> more data than we could ever allow in fork.c, and possibly detect
>> attacks that this patch would miss if a clever attacker stayed just
>> below the limit.
>>
>>        -- Chris
>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Simon Arlott

Re: Fork Bombing Patch

[Anand Jahagirdar]

Hi
   consider a case:
if non root user request admin for more number of processes than root
user,admin needs to modify settings in /etc/security/limits.conf file
and if that user is not trustworthy and if does fork bombing attack it
will kill the box.
(I have already tried this attack). in that case this loop will work,
but by the time attack might have killed the box (Bcoz so many
processes has already been created at that time) . so in that case
admin wont come to know that what has happened.

Like this there are many cases..(actually these cases has already been
discussed On LKML 2 months before in my thread named "fork bombing
attack").
in all these cases this printk helps adminstrator a lot.


Anand

On 8/29/07, Simon Arlott <simon@fire.lp0.eu> wrote:
> On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
> > Hi
> >                 printk_ratelimit function takes care of flooding the
> > syslog. due to printk_ratelimit function syslog will not be flooded
> > anymore. as soon as administrator gets this message, he can take
> > action against that user (may be block user's access on server). i
> > think the my fork patch is very useful and helps administrator lot.
> >                 i would also like to mention that in some of the cases
> > ulimit solution wont work. in that case fork bombing takes the machine
> > and server needs a reboot. i am sure in that situation this printk
> > statement helps administrator to know what has happened.
>
> If ulimit "wont work" in some situations, how is it going to trigger this printk?
> (When doesn't it work?)
>
> > Anand
> >
> > On 8/24/07, Chris Snook <csnook@redhat.com> wrote:
> >> Krzysztof Halasa wrote:
> >> > Hi,
> >> >
> >> > "Anand Jahagirdar" <anandjigar@gmail.com> writes:
> >> >
> >> >>    I am forwarding one more improved patch which i have modified as
> >> >> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
> >> >> i have added one more if block to check hard limit. how good it is?
> >> >
> >> > Not very, still lacks "#ifdef CONFIG_something" and the required
> >> > Kconfig change (or other runtime thing defaulting to "no printk").
> >>
> >> Wrapping a single printk that's unrelated to debugging in an #ifdef
> >> CONFIG_* or a sysctl strikes me as abuse of those configuration
> >> facilities.  Where would we draw the line for other patches wanting to
> >> do similar things?
> >>
> >> I realized that even checking the hard limit it insufficient, because
> >> that can be lowered (but not raised) by unprivileged processes.  If we
> >> can't do this unconditionally (and we can't, because the log pollution
> >> would be intolerable for many people) then we shouldn't do it at all.
> >>
> >> Anand -- I appreciate the effort, but I think you should reconsider
> >> precisely what problem you're trying to solve here.  This approach can't
> >> tell the difference between legitimate self-regulation of resource
> >> utilization and a real attack.  Worse, in the event of a real attack, it
> >> could be used to make it more difficult for the administrator to notice
> >> something much more serious than a forkbomb.
> >>
> >> I suspect that userspace might be a better place to solve this problem.
> >>  You could run your monitoring app with elevated or even realtime
> >> priority to ensure it will still function, and you have much more
> >> freedom in making the reporting configurable.  You can also look at much
> >> more data than we could ever allow in fork.c, and possibly detect
> >> attacks that this patch would miss if a clever attacker stayed just
> >> below the limit.
> >>
> >>        -- Chris
> >>
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
>
> --
> Simon Arlott
>

Re: Fork Bombing Patch

[Chris Snook]

Anand Jahagirdar wrote:
> Hi
>    consider a case:
> if non root user request admin for more number of processes than root
> user,admin needs to modify settings in /etc/security/limits.conf file
> and if that user is not trustworthy and if does fork bombing attack it
> will kill the box.

If root is dumb enough to give the user whatever privileges they ask for, 
fork-bombing is the least of your problems.

> (I have already tried this attack). in that case this loop will work,
> but by the time attack might have killed the box (Bcoz so many
> processes has already been created at that time) . so in that case
> admin wont come to know that what has happened.

On large multi-user SMP systems, the default ulimits will keep the box 
responsive, if sluggish.  Perhaps you should file a bug with your distribution 
if you believe the default settings in limits.conf are too high.  There's no way 
to algorithmically distinguish a forkbomb from a legitimate highly-threaded 
workload.

> Like this there are many cases..(actually these cases has already been
> discussed On LKML 2 months before in my thread named "fork bombing
> attack").
> in all these cases this printk helps adminstrator a lot.

What exactly does this patch help the administrator do?  If a box is thrashing, 
you still have sysrq.  You can also use cpusets and taskset to put your root 
login session on a dedicated processor, which is getting to be pretty cheap on 
modern many-core, many-thread systems.  Group scheduling is in the oven, which 
will allow you to prioritize classes of users in a more general manner, even on 
UP systems.

> On 8/29/07, Simon Arlott <simon@fire.lp0.eu> wrote:
>> On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
>>> Hi
>>>                 printk_ratelimit function takes care of flooding the
>>> syslog. due to printk_ratelimit function syslog will not be flooded

Um, no.  printk_ratelimit is on the order of *seconds*.  This prevents error 
conditions from causing the system to spend all of its CPU and I/O time logging. 
  It does very little to prevent log spamming.  If I sent you an email every 
second, it would make it much more difficult for you to find other messages in 
your inbox.  It's possible (easy, even) to write a forkbomber that doesn't 
actually harm system responsiveness, but will still trigger this printk as fast 
as possible.  If we merge this patch, every cracking toolkit in existence will 
add such a feature, because log spamming makes it harder for the administrator 
to find more important messages, and even if the administrator uses grep 
judiciously to filter them out, that doesn't help if logrotate has already 
deleted the log containing the information they need to keep /var/log from 
filling up.

>>> anymore. as soon as administrator gets this message, he can take
>>> action against that user (may be block user's access on server). i
>>> think the my fork patch is very useful and helps administrator lot.

You still haven't explained why this can't be done in userspace.  If forkbombing 
is a serious threat (and it's not) you can run a forkbomb monitor with realtime 
priority that won't be severely impacted by thrashing among normal priority 
processes.  Userspace has room for much more sophisticated processing anyway, so 
doing this in the kernel doesn't make much sense.

>>>                 i would also like to mention that in some of the cases
>>> ulimit solution wont work. in that case fork bombing takes the machine
>>> and server needs a reboot. i am sure in that situation this printk
>>> statement helps administrator to know what has happened.

SysRq-t makes it quite obvious that the system has been forkbombed, allowing the 
administrator to lower ulimits if the box can't handle the load permitted by the 
default settings.  Sometimes SysRq is inconvenient due to lack of physical 
access, which is why I wrote hangwatch[1].

Hangwatch monitors /proc/loadavg and writes the specified set of SysRq triggers 
into /proc/sysrq-trigger when the specified load average is exceeded, with the 
specified frequency.  It doesn't require forks or dynamic memory allocation, so 
it works basically any time the box isn't locked up enough to trigger NMI 
watchdog, though realtime users may want to run it with chrt priority.  It's 
very simple, but it's proven so effective that there really hasn't been much 
need to develop it further since I initially wrote it a year ago.

Given how much we can already do in userspace, I don't really see a need to 
implement this in the kernel.  If you'd like me to add features to hangwatch, 
let's talk about that.  You can even fork it yourself, since it's GPL.

	-- Chris

[1] http://people.redhat.com/csnook/hangwatch/

Re: Fork Bombing Patch

[Kyle Moffett]

On Aug 29, 2007, at 09:49:01, Chris Snook wrote:
>> Like this there are many cases..(actually these cases has already  
>> been discussed On LKML 2 months before in my thread named "fork  
>> bombing
>> attack").  in all these cases this printk helps adminstrator a lot.
>
> What exactly does this patch help the administrator do?  If a box  
> is thrashing, you still have sysrq.  You can also use cpusets and  
> taskset to put your root login session on a dedicated processor,  
> which is getting to be pretty cheap on modern many-core, many- 
> thread systems.  Group scheduling is in the oven, which will allow  
> you to prioritize classes of users in a more general manner, even  
> on UP systems.

I've also set up systems where there is a carefully rate-limited  
SCHED_RR 98 ssh process (NIC interrupt thread is SCHED_RR 99) behind  
an additional set of rate-limiting rules in IPtables.  Basically, no  
matter what somebody is doing to the workstation, even if I let them  
create as many processes as they want or get the box completely into  
a swap storm, I can "ssh -p 222 root@some.box".  Once it connects I  
type in two passwords through a custom PAM plugin and then have my  
login script touch /etc/nologin and send SIGSTOP to every

The resource consumption issue is immediately over and I can go about  
kicking the user and filling out all the icky paperwork.

Cheers,
Kyle Moffett

Re: Fork Bombing Patch

[Chris Snook]

Anand Jahagirdar wrote:
> Hi
>    First of all Very sorry for late reply. I just gone through Hangwatch 
> code. It triggers the SysRq whenever there is hang, but in case of fork 
> bombing attack kernel itself prevents it, if setting for every user in 
> /etc/security/limits.conf are properly set. due to this setting there is 
> no "hang" in the system in case of fork bombing attack.
>     My aim is just to inform administrator about a user who* *has 
> crossed his process limit. If non root user is crossing the limit 
> its not good(considered as threat) from system(kernel) point of view 
> thats why limits are set. so if any non root user is crossing the 
> limit admin should know it. isnt it? 
>     To get this user limit information there is no provision in user 
> space, only kernel has the information. i was unable to print any kind 
> of message in hangwatch regarding a user who has crossed the limit. i am 
> ok with doing it in user space, but user space dont have sufficient 
> information regarding process limit. hangwatch aims to prevent system 
> from hang, which differs from my aim (to inform administrator about 
> limit crossing).chris please suggest. am i missing something?

Yes.  Your patch creates a denial of service in the process of warning 
that it has prevented a different denial of service.  Syslog syncs after 
each logged message, to ensure that if the system goes down, its dying 
gasps make it to disk.  Even if you ratelimit the printk, you still get 
log flooding, which can fill your /var/log partition, causing all sorts 
of things to go wrong, particularly since /var/log is on the root 
filesystem in most distros.  Even if you mitigate this with aggressive 
logrotate settings, you lose important messages to make room for these 
unimportant messages.  Even if you create an enormous /var/log 
partition, you still create a condition where the flood of messages can 
hide something more important when a human reads through the logs to try 
to figure out what's going on.

The only way this would be acceptable is if it were at a debug loglevel, 
so it would be off by default.  The problem is, it's not a kernel 
debugging feature, it's a userspace debugging feature.  This just isn't 
the right place to solve your problem.  If you feel very strongly about 
it, feel free to patch it into your own kernels, but please don't put it 
in mine.

-- Chris

> On 8/29/07, *Chris Snook* <csnook@redhat.com <mailto:csnook@redhat.com>> 
> wrote:
> 
>     Anand Jahagirdar wrote:
> 
>         Hi
>           consider a case:
>         if non root user request admin for more number of processes than
>         root
>         user,admin needs to modify settings in /etc/security/limits.conf
>         file
>         and if that user is not trustworthy and if does fork bombing
>         attack it
>         will kill the box.
> 
> 
>     If root is dumb enough to give the user whatever privileges they ask
>     for, fork-bombing is the least of your problems.
> 
>         (I have already tried this attack). in that case this loop will
>         work,
>         but by the time attack might have killed the box (Bcoz so many
>         processes has already been created at that time) . so in that case
>         admin wont come to know that what has happened.
> 
> 
>     On large multi-user SMP systems, the default ulimits will keep the
>     box responsive, if sluggish.  Perhaps you should file a bug with
>     your distribution if you believe the default settings in limits.conf
>     are too high.  There's no way to algorithmically distinguish a
>     forkbomb from a legitimate highly-threaded workload.
> 
>         Like this there are many cases..(actually these cases has
>         already been
>         discussed On LKML 2 months before in my thread named "fork bombing
>         attack").
>         in all these cases this printk helps adminstrator a lot.
> 
> 
>     What exactly does this patch help the administrator do?  If a box is
>     thrashing, you still have sysrq.  You can also use cpusets and
>     taskset to put your root login session on a dedicated processor,
>     which is getting to be pretty cheap on modern many-core, many-thread
>     systems.  Group scheduling is in the oven, which will allow you to
>     prioritize classes of users in a more general manner, even on UP
>     systems.
> 
>         On 8/29/07, Simon Arlott <simon@fire.lp0.eu> wrote:
> 
>             On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
> 
>                 Hi
>                                printk_ratelimit function takes care of
>                 flooding the
>                 syslog. due to printk_ratelimit function syslog will not
>                 be flooded
> 
> 
>     Um, no.  printk_ratelimit is on the order of *seconds*.  This
>     prevents error conditions from causing the system to spend all of
>     its CPU and I/O time logging.  It does very little to prevent log
>     spamming.  If I sent you an email every second, it would make it
>     much more difficult for you to find other messages in your inbox.
>      It's possible (easy, even) to write a forkbomber that doesn't
>     actually harm system responsiveness, but will still trigger this
>     printk as fast as possible.  If we merge this patch, every cracking
>     toolkit in existence will add such a feature, because log spamming
>     makes it harder for the administrator to find more important
>     messages, and even if the administrator uses grep judiciously to
>     filter them out, that doesn't help if logrotate has already deleted
>     the log containing the information they need to keep /var/log from
>     filling up.
> 
>                 anymore. as soon as administrator gets this message, he
>                 can take
>                 action against that user (may be block user's access on
>                 server). i
>                 think the my fork patch is very useful and helps
>                 administrator lot.
> 
> 
>     You still haven't explained why this can't be done in userspace.  If
>     forkbombing is a serious threat (and it's not) you can run a
>     forkbomb monitor with realtime priority that won't be severely
>     impacted by thrashing among normal priority processes.  Userspace
>     has room for much more sophisticated processing anyway, so doing
>     this in the kernel doesn't make much sense.
> 
>                                i would also like to mention that in some
>                 of the cases
>                 ulimit solution wont work. in that case fork bombing
>                 takes the machine
>                 and server needs a reboot. i am sure in that situation
>                 this printk
>                 statement helps administrator to know what has happened.
> 
> 
>     SysRq-t makes it quite obvious that the system has been forkbombed,
>     allowing the administrator to lower ulimits if the box can't handle
>     the load permitted by the default settings.  Sometimes SysRq is
>     inconvenient due to lack of physical access, which is why I wrote
>     hangwatch[1].
> 
>     Hangwatch monitors /proc/loadavg and writes the specified set of
>     SysRq triggers into /proc/sysrq-trigger when the specified load
>     average is exceeded, with the specified frequency.  It doesn't
>     require forks or dynamic memory allocation, so it works basically
>     any time the box isn't locked up enough to trigger NMI watchdog,
>     though realtime users may want to run it with chrt priority.  It's
>     very simple, but it's proven so effective that there really hasn't
>     been much need to develop it further since I initially wrote it a
>     year ago.
> 
>     Given how much we can already do in userspace, I don't really see a
>     need to implement this in the kernel.  If you'd like me to add
>     features to hangwatch, let's talk about that.  You can even fork it
>     yourself, since it's GPL.
> 
>            -- Chris
> 
>     [1] http://people.redhat.com/csnook/hangwatch/
>     <http://people.redhat.com/csnook/hangwatch/>
> 
>