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/
-
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]
