lkml.org 
[lkml]   [2007]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Fork Bombing Patch
    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
    >
    -
    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/

    \
     
     \ /
      Last update: 2007-08-20 16:57    [W:4.420 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site