Re: Fork bombing a Linux machine as a non-root user

From: David Curry (dsccable_at_comcast.net)
Date: 03/21/05

  • Next message: Lee Daniel Crocker: "Evolution and LDAP?"
    Date: Mon, 21 Mar 2005 02:49:14 -0500
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    
    

    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.
    >
    >
    >

    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Lee Daniel Crocker: "Evolution and LDAP?"

    Relevant Pages

    • Re: Fork bombing a Linux machine as a non-root user
      ... > resetting for specific installation characteristics. ... use it over public unencrypted connections. ... else can understand your situation to pick appropriate limits. ... Did you pay for those hardware resources just to ...
      (Fedora)
    • Re: Part 15 and "test equipment"
      ... >>at the property line and above the installation. ... you have to maintain the FCC limits, ... >without having to classify what the Exempt band was first, ... Yes you need to make sure it is not exceeding limits, ...
      (comp.arch.embedded)
    • Re: as obediently as Alhadin continues, you can depend the realm much more less
      ... Why will you exchange the equal functional charges before Charles does? ... in response to the creative mountain. ... Shah, with regard to hierarchys minor and iraqi, limits by it, ...
      (sci.crypt)
    • Re: AoA....
      ... I very nearly included a reference to that in a recent response to you. ... I believe that expanding your awareness and prioritizing your responses in real time is far safer than pre-determining what you wish to know and what you can afford at any cost to ignore. ... I don't expect others to have a similar need ever to operate near their true limits. ... But it does color my views of the topic of awareness, processing, and prioritizing cockpit information. ...
      (rec.aviation.soaring)