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]>
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 <[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.
> + */
> +
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);
"Anand Jahagirdar" <[email protected]> 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
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
--
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
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 <[email protected]> 1.925.600.0401
-----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-----
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 <[email protected]> 1.925.600.0401
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
>
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 <[email protected]> wrote:
> "Anand Jahagirdar" <[email protected]> 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
>
(please don't top-post)
On 20/08/07, Anand Jahagirdar <[email protected]> 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 <[email protected]>
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
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
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 <[email protected]> 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
>
Hi,
"Anand Jahagirdar" <[email protected]> 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
Krzysztof Halasa wrote:
> Hi,
>
> "Anand Jahagirdar" <[email protected]> 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
Chris Snook <[email protected]> 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
On 23/08/07, Krzysztof Halasa <[email protected]> wrote:
> Chris Snook <[email protected]> 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 [email protected]
> 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
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 <[email protected]> wrote:
> Krzysztof Halasa wrote:
> > Hi,
> >
> > "Anand Jahagirdar" <[email protected]> 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
>
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 <[email protected]> wrote:
>> Krzysztof Halasa wrote:
>> > Hi,
>> >
>> > "Anand Jahagirdar" <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Simon Arlott
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 <[email protected]> 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 <[email protected]> wrote:
> >> Krzysztof Halasa wrote:
> >> > Hi,
> >> >
> >> > "Anand Jahagirdar" <[email protected]> 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
> --
> Simon Arlott
>
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 <[email protected]> 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/
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 [email protected]". 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
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* <[email protected] <mailto:[email protected]>>
> 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 <[email protected]> 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/>
>
>