On Sat, 19 Mar 2005 21:03:38 +0800, Ow Mun Heng <Ow.Mun.Heng@xxxxxxx> wrote: > On Fri, 2005-03-18 at 15:25 -0500, Dave Jones wrote: > > On Fri, Mar 18, 2005 at 03:18:00PM -0500, Scot L. Harris wrote: > > > > > And yes there are tools available to help mitigate the potential problem > > > as you pointed out. But why not set a default limit instead of leaving > > > it open? > > > > Because then we get flooded with "I cant run two copies of openoffice, wtf?", > > "concurrent users of ftpd downloading iso's or other large files goes bang" > > and many other similar bugs. > > But shouldn't there be some sane limit already applied? As a normal > user, I believe having ~300 user proceses would be more than enough? > > Why not ship it with a reasonable sane limit? 1000 perhaps? How about this idea: Implement a process _creation_rate_ limit. That way, if someone did try to fork-bomb the system, it would see the enormous number of fork() commands in a short period of time and do something to slow the process down or kill it and its children. The only reason to start up several hundred processes within a few seconds is to fork-bomb the system (at least I cannot think of another reason). This way, a user can still create as many processes as needed (up to the large default ulimit) and a simple fork-bomb attack would be stopped. I guess this could be seen almost like an anit-virus program (but one that was implemented in the kernel). It would use sanity checks to make sure that programs were behaving. Any program that was caught violating the sanity checks (which could include rapid process creation and any other activity that could be potentially dangerous to the stability of the system, like large amounts of memory requested rapidly, etc) could be either: descheduled, killed, or perhaps decheduled and the user prompted as to what to do (the issue here is, who gets to make that decision, if I'm the fork-bomber, of course I want to let it go on). What do y'all think? I know this wouldn't be trivial to implement like a lower default ulimit, but might be a good security enhancement to the kernel, though granted such an attack is highly unlikely. Most who want to break into a system want to use it (eg to send spam) not render it useless. But is Linux continues to become as popular as it is, we may start to see the development of viruses for Linux in the future, and this would be an easy target. Jonathan
