Hello All
As per the discussion in the thread with subject as
Patch Related with Fork Bombing Attack on LKML, I request you for the
inclusion of my attached patch named "fork.patch".
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]>
> + /*
> + * 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;
> + }
please run scripts/checkpatch.pl against your patch. It will point
out numerous problems with the coding style. Also, I think a space
between KERN_CRIT and " would look better too.
- R.
On Jun 12 2007 10:04, Roland Dreier wrote:
> > + /*
> > + * 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;
> > + }
>
>please run scripts/checkpatch.pl against your patch. It will point
>out numerous problems with the coding style. Also, I think a space
>between KERN_CRIT and " would look better too.
And uid is %lu, not %d.
And s/its/his/ or s/its/the/;
Jan
--
On Tue, June 12, 2007 18:32, Jan Engelhardt wrote:
> On Jun 12 2007 10:04, Roland Dreier wrote:
>> > + /*
>> > + * 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;
>> > + }
Why does this need to be KERN_CRIT? You can't assume that every time a process limit is reached that it's a
fork bomb.
--
Simon Arlott
On Wednesday 13 June 2007 07:34:09 Simon Arlott wrote:
> On Tue, June 12, 2007 18:32, Jan Engelhardt wrote:
> > On Jun 12 2007 10:04, Roland Dreier wrote:
> >> > + /*
> >> > + * 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;
> >> > + }
>
> Why does this need to be KERN_CRIT? You can't assume that every time a
> process limit is reached that it's a fork bomb.
I think the reasoning here is to alert the administrator(s) to the possibility
that somebody has just tried a fork-bomb. A better test, IMHO, would be to
check how fast the processes are being spawned and whether a large percentage
share the same parent. (Those two taken together would better spot most
fork-bombs, including the very simple types that are just a simple one-liner)
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
Daniel Hazelton <[email protected]> writes:
> I think the reasoning here is to alert the administrator(s) to the
> possibility
> that somebody has just tried a fork-bomb. A better test, IMHO, would be to
> check how fast the processes are being spawned and whether a large
> percentage
> share the same parent. (Those two taken together would better spot most
> fork-bombs, including the very simple types that are just a simple one-liner)
Not sure if it's a great idea at all. If the attacker is dumb then the
administrator already has everything he/she needs (and more) to adjust
the luser attitude.
If it's a serious attack then the attacker will evade the tests anyway
(but he/she may not be able to overcome the limits and the admin
still have all required info etc).
If we print such things then perhaps the next patch in queue should
warn us about users trying to access /etc/shadow or issuing some
configuration syscalls?
>From a different point of view it would be alerting sysadmins about
a user who tried to create one more process than he/she was allowed
to. Isn't it crazy?
--
Krzysztof Halasa