From owner-freebsd-security Tue Jul 10 23:33: 9 2001 Delivered-To: freebsd-security@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id D37A437B401 for ; Tue, 10 Jul 2001 23:33:05 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id EC2825D01F; Wed, 11 Jul 2001 01:32:54 -0500 (CDT) Date: Wed, 11 Jul 2001 01:32:54 -0500 From: Alfred Perlstein To: Matt Dillon Cc: "Robert E. Lee" , Dag-Erling Smorgrav , Ted Mittelstaedt , js43064n@pace.edu, freebsd-security@FreeBSD.ORG Subject: Re: Kernel Panic Message-ID: <20010711013254.F1894@sneakerz.org> References: <20010710230329.A1894@sneakerz.org> <200107110605.f6B657X24415@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200107110605.f6B657X24415@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jul 10, 2001 at 11:05:07PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Matt Dillon [010711 01:05] wrote: > > :It'd be almost trivial to limit the amount of outstanding IO on a > :per uid basis. Have time for a patch? :) > : > :Hint: > :store the amount of IO in the uidinfo struct, if you go out of > :bounds, sleep on the outstanding buf counter address for a short > :time (*), if the user completes IO, then issue a wakeup. > : > :(*) the reason you can not sleep inifinitely is because you may cause > :a deadlock situation against yourself when writing out dirty buffers, > :or maybe not.. ? > : > :Anyhow, that should allow for throttling. > : > :-- > :-Alfred Perlstein [alfred@freebsd.org] > > Appropriate resource limits and a properly configured system can go a > long way towards preventing a crash. Expecting an untuned, > insufficiently endowed machine to be able to handle a DOS attack from > a shell prompt is unrealistic. The machine can't really tell the > difference between something like the above and, say, someone starting > up a copy of gnome, or mozilla, or ircd, or a user account dedicated to > serving cvsup. You certainly can't tell by looking at the I/O load... > the above script would only max out the disk's seeking (which a lot > of programs can do), and it does not actually represent any significant > amount of I/O bandwidth relative to, say, a program copying a large > file. > > So the fix is really nothing more then the sysadmin setting > appropriate resource limits, monitoring the machine, and blowing away > any idiot user who does the above. The fix is certainly not to try > to make the OS magically figure out that someone is running a DOS > attack from a shell prompt and having it arbitrarily throttle the > uid! I totally agree that 'rmuser' is quite often the best fix for problems such as this. It still would be nice to be able to throttle IO on a large multiuser system for those that need it. A large sequential IO should be serviced faster than a wide seeking IO so that it shouldn't penalize people doing sequential too badly. Anyhow, this would really just be to implement a QoS type solution for large multiuser systems, it would not be enabled by default, in fact it probably would have to fall under some compilation option if implemented. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message