:Hm. It's misunderstanding.
:
:I don't agree with you about the following point.
:Thus, the situation might happen.
:
:> Give me a shell and I can crash any machine. If you are assuming
:> hostile users, you cannot assume that your magic overcommit protection
:> will save your server. Saying that the kernel and application behave
:> properly is a cop-out, because it's virtually impossible to guarentee
:> that for every situation. The chance of a user blowing up the server
:> by finding a bug or a hole somewhere is much, much greater then the chance
:> of a user running the system out of swap.
:
:If you are trying to say that it is easier to crash FreeBSD than
:the system out of swap. You might be wrong.
:
:Memory consumption is quite easy, almost every programmer can do it
:with normal user privilege.
:If there is a bug which crashes FreeBSD and which is easier to write
:than memory consumption, it is better to fix the bug.
:--
:soda
It's a lot harder then you think. Again, taking my BEST experience...
the shell machines had 128MB to 512MB of ram and usually on the order
of a gig of swap. Being shell machines we had our share of IRC hackers.
We could always tell when there were no root holes on the systems because
the IRC hackers would get into an account (users often logged in from
public libraries or other unsecure locations and got their passwords
sniffed).. Where was I? Oh yah, the IRC hackers would get into an
account, try all their root tricks and fail, then get frustrated and
attempt to crash the machine from the user's account.
They were *never* able to run our machines out of swap. They could make
them page heavily, but they could never run them out of swap. Before
they even got swap 20% full the load would come to the attention of a
sysop who would stare bemusedly at the idiot IRC hacker, then send him
a few snide remarks with write before disabling the account and killing
the processes.
On the otherhand, there are a number of known ways to crash a FreeBSD
box that do not involve running it out of stack. The most interesting
one that I know of is with a spoofed-packet attack that randomizes
the source IP. FreeBSD builds up temporary route table entries for
the return packet and panics with a kernel memory limit being hit on
the route table. Or I should say it used to. I've fixed that little
problem.
There are other ways. For example, even if a user account is resource
limited, root processes (such as sendmail, popper, identd, and so forth)
are not. Attacks against these servers generally result in very high
loads and sometimes make it difficult to login to fix the problem, but do
not result in running out of swap.
With today's modern high capacity disk drives, a properly configured
multi-user system will have enough swap that running it out is difficult
to say the least. Even my home server has 512MB of swap and could
easily have several gigabytes if I thought it necessary. We always
recommend that you allocate swap sufficient for your needs - usually
2xMEM. But the word "sufficient" can also mean to allocate extra swap
if you believe that the runaways are common enough to cause a problem.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
