Re: Fork Bombing Patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]>


------------------------------------------------------------------------

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
-
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 read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux