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 <[EMAIL PROTECTED]> 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 <[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/
