Fork bombing a Linux machine as a non-root user

[David Curry]

Les Mikesell wrote:

>On Sat, 2005-03-19 at 13:36, David Curry wrote:
>  
>
>>Discussion in this thread frequently reflected an unwarranted, 
>>underlying assumption.   Namely, that linux/unix experts are intalling 
>>the OS, know how the system will be used, and act immediately after 
>>installation to reset default installation resource limits to 
>>appropriate levels. It is obvious to me from thread discussion that that 
>>assumption is invalid. 
>>    
>>
>
>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.

>The other assumption
>is that the person who adds logins and and gives out passwords
>to others knows more about whether their access to certain
>resources should be limited or if they can be trusted to
>use the full power of the box.
>
>  
>
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.

>> Rather the discussion suggests many/some 
>>respondents had the author's (and my) grasp of the resource limit 
>>issue.  It is past time for the linux enthusiats touting linux as more 
>>secure than windows to get acquainted with the result of parsing the 
>>word assume into ass-u-me!
>>    
>>
>
>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. 

>>How many people on this list purchase automobiles with the expectation 
>>of sitting in the driver's seat, turning the ignition key and start 
>>forward at full throttle with windshield wipers on, head lights on at 
>>high beam and the sound system blaring at top volume?  I predict the 
>>answer to that question is zero!
>>    
>>
>
>Automobiles do nothing to stop you from driving into a brick wall
>at full speed if you choose to do so.  Likewise your OS won't
>(and shouldn't, by default) second-guess your decision to 
>start an inefficiently large number of processes. 
>
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.

>In both cases
>there are any number of ways to learn better practices.
>
>Giving  passwords to others to use your system is very much like
>giving out the keys to your car.  If you don't trust someone to
>use it wisely, either don't do it or learn how to control what
>they can do first.  
>
Established best practice is to guard passwords and limit system access 
to "trusted" individuals.

>Note that 'fork bombs' don't happen by
>accident and require login/password access to be given to the
>person that can set them off.   
>
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.

>In the same way that you are
>the only one who can decide who you trust to drive your car,
>you are the only one who can decide how to issue can control
>  
>
>logins for others on your computer 
>
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?

>- and if you crash it yourself
>it doesn't make any sense to blame someone else.
>  
>
I agree that if I crash my system, I have only myself to blame.   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.