Fork bombing a Linux machine as a non-root user

[David Curry]

Les Mikesell wrote:

Just read your comments below, Les.  The list deserves a response but it 
will have to wait.  Your views don't deserve any of my early a.m. time. 

>On Sat, 2005-03-19 at 21:29, David Curry wrote:
>  
>
>>>No, the assumption is that the person installing the OS, expert or
>>>not, knows more about it's capabilities than the person who
>>>built the distribution that will run on anything from a P100
>>>or less to a multi-cpu, multi-Ghz box.  
>>>
>>>      
>>>
>>Your interpretation would be much better supported if there was some 
>>documentation available to that "person installing the OS" which 
>>informed them of the default installation settings and advisability of 
>>resetting for specific installation characteristics.
>>    
>>
>
>I simply can't believe that anyone who is obviously on the
>internet and capable of joining a mailing list can possibly
>think there is any lack of documentation available.  It is true
>that a free product generally does not come with a marketing
>force that will take you to lunch or golf and hold your hand
>while you learn about the product, but the ulimit concept has
>been documented for anyone who cares to read about it long
>before Linux was even around (remember how Linux is a free
>implementation of the unix API...).
>
>  
>
>>This argument overlooks the specifc kind of concern that prompted the 
>>thread originating author to pose his question.  Namely, vulnerability 
>>of the system to fork bombing if it is hacked.
>>    
>>
>
>Well, OK - don't get hacked.  A fork bomb is one of the least
>destructive things a hacker could do once in. Keep your system
>updated and you are unlikely to have a vulnerability exploited.
>Keep your password to yourself, don't write it down, and don't
>use it over public unencrypted connections.
>
>  
>
>>>You are the one making the wrong assumption if you think the OS
>>>distributors know more about how *your* PC's resources should be
>>>used or how much you trust the other users on your machine.
>>>
>>> 
>>>
>>>      
>>>
>>See my responses to your two preceeding assertions. 
>>    
>>
>
>I saw them, but they do nothing to address the point that no one
>else can understand your situation to pick appropriate limits.
>
>  
>
>>Second guessing an ops "decision to start an inefficiently large number 
>>of processes" would be to predetermine limits below capacity and not 
>>provide a means of changing them.  Setting installation default at a 
>>level large enough to handle installation while providing both advice of 
>>those default settings and a means of changing them to suit the user 
>>would be prudent as well as rational.  It would be better practice Red 
>>Hat/Fedora than has been followed in the past.
>>    
>>
>
>That would be like buying a car that would not go above 5 mph until
>you prove your proficiency under the hood to remove the limit.  While
>it might be a good practice for some definition of the term, it isn't
>what anyone would expect.
>
>  
>
>>Is it a fact that 'fork bombs' require "login/password access ... to set 
>>them off."  We recently read here on fedora-list about a system that had 
>>been taken over and was being used without authorization as a mail 
>>server.  A script of unknown original found in the /tmp directory set up 
>>the service.
>>    
>>
>
>Breakins are equivalent to gaining a login/password.  Finding out about
>it through a system crash or slowdown is probably better than letting
>an outsider continue to use your system resources and likely intercept
>logins and passwords you are using in your outbound connections to
>other sites.  In other words, the fork bomb potential is the least of
>your problems after a breakin.
>
>  
>
>>Controling system access is the objective.  But, doesn't it make sense 
>>to maintain multi-layered defenses so if the outer perimeter is breached 
>>more hurdles exist to thwart stealth attackers?
>>    
>>
>
>It doesn't make sense to impose limits on the legitimate user(s) of the
>system by default.  Did you pay for those hardware resources just to
>be prevented from using them to their limits?
>
>  
>
>>And, to limit the chances of anyone else breaching my system's security
>>and damaging my system, I have now established new, lower resource
>>allocation limits in addition to other measures.  I have turned off all
>>the services I do not need, my broadband modem is placed in standby mode
>>whenever I do not intend to access the internet, my system is turned off
>>if I am going to be away from it for any period of time while someone else
>>has access to the machine.
>>    
>>
>
>Now add regular backups on media taken to another location to that and
>you can consider your files to be pretty safe.  Otherwise hardware
>failure or operator error are still your most likely ways to lose
>data.   Personally I'd take the risk of leaving ssh connections
>available from outside if you ever have any reason to need it.
>There have been exploits in the past but if you keep your system
>updated there should not be much risk now.  
>
>  
>