Date: Sat, 10 Apr 1999 14:29:38 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Robey <chuckr@mat.net> Cc: Kevin Day <toasty@home.dragondata.com>, hasty@rah.star-gate.com, dv@dv.ru, green@unixhelp.org, freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) Message-ID: <199904102129.OAA01853@apollo.backplane.com> References: <Pine.BSF.4.10.9904101711180.391-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Matt, I agree with what you're saying, but what would you think about
:something that would take a look at the total cpu time that a process
:group had accumulated in the previous 120 seconds. That would be, I
:think, plenty long enough to catch most inadvertent things, and just
:kill the process leader. You could allow some users to have very high
:limits, but an attacker, someone purposely bringing the machine down (a
:hacker) would find only 2 minute capabilities.
:
:Do you think something like this would still contribute to the cascade
:failure scenarios?
This would contribute to the number of complaints you receive from
users about 'things getting killed at odd times'. Here you are assuming
that users only run short-term cpu-intensive processes. This is, in fact,
not true.
For example, many BEST users run log processing scripts in the wee hours
of the morning. These scripts are often cpu-intensive and can take as
much as half an hour of cpu time before completing.
While I instituted resource limits on BEST users, I had to make them
relatively generous because BEST users often run things legally that
eat a lot of resources. File descriptors ( log processing into breakdown
files ), processes ( screen sessions ), memory ( tin, emacs ), cpu
( log processing, mailing list run, procmail ).
Also, we do not want to penalize users when their accounts or web pages
get attacked. If a user's web page is attacked, dozens of CGI's a second
might be run on that user's behalf. The machine needs to be able to grin
and brunt it while we go after the source of the attack to prevent the
attacker from gaining his goal of disrupting that user.
Which means: Even if you had such a mechanism, you would have to set
*very* generous limits in order to avoid having it accidently kill a
user's legitimate work.
As I said, it really takes a human to figure out the difference between
a mistake, a hack, or a valid operation.
-Matt
Matthew Dillon
<dillon@backplane.com>
:----------------------------+-----------------------------------------------
:Chuck Robey | Interests include any kind of voice or data
:chuckr@picnic.mat.net | communications topic, C programming, and Unix.
:213 Lakeside Drive Apt T-1 |
:Greenbelt, MD 20770 | I run picnic (FreeBSD-current)
:(301) 220-2114 | and jaunt (Solaris7).
:----------------------------+-----------------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904102129.OAA01853>