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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Curry said:
> William Hooper wrote:
>
>
>> David Curry said:
>>
>>
>>
>>> The thing about hackers, though, is that only they know what it is
>>> they want to do. A fork bomb may be a lesser risk than something else,
>>> but it is nevertheless a risk that many newcomers to linux are unaware
>>> of.
>>>
>>>
>>
>> At the point that a malicious person can run any arbitrary process on
>> your machine you no long have control over it, regardless if they are
>> able to fork bomb the machine or not.
>>
>>
>>
> Perhaps, and perhaps not.  I can envision a scenario in which a hacker
> reaches user space and authorities, but has not penetrated the user/root
> divide.

You aren't envisioning far enough, then.

[snip]
>>> A better practice would be to set installatioin defaults at levels
>>> that will clearly support installation of the OS, make those default
>>> installation values known to the ops, and expect ops to address the
>>> resource allocation issue at time of installation.
>>>
>>>
>>
>> Which leads to a bunch of people complaining about the defaults having
>> to be changed.  You yourself commented in another thread about having to
>>  change the defaults for sound settings was an "irritating PITA".
>>
>>
>>
>
> Two points.  First, your logic clearly implies that a system op
> installing with historic default settings for user resource permissions
> usually does not lift a finger.  Just installs and goes.

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

Sound familiar?

> THAT is a silly
> argument for someone to make after citing Dave Jones' earlier remarks
> which made the point that OS distributors are not in a position to use
> default settings suitable for all ops on all systems.  And, the argument
> implies that either all system ops can disregard the risk of fork bombing
> regardless of how their systems or used or that the system ops have no
> idea of what the default settings are and the risks those settings expose
> them to.

No, it implies that a system op, who is running a machine with untrusted
local users, will be adjusting this value anyway.  I have yet to be
convinced that there is a real problem any other scenario.

> Second, sound card default settings and user resource limits are
> not analogous.  System resource allocations apply to all systems whereas
> sound card default settings apply to only those systems with sound
> chips/cards installed.  It seems to me that if someone has CHOSEN a system
> with sound capabilities then it is rational to presume that the system op
> expects/wants sound.  Past Fedora releases have compelled every op with
> sound hardware to change the default settings while the issue simply does
> not arise for system ops without sound hardware.  That is, 100% of ops
> with sound hardware must take explicit action to override the default
> settings.

Above you suggest making 100% of the people installing the OS change the
default user resource limits.  The only difference I see is that more
people would have to change the defaults.

--
William Hooper


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux