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.
--
Les Mikesell
les@xxxxxxxxxxxxxxxx
