From owner-freebsd-hackers Tue Jul 13 17:26: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1837F15157; Tue, 13 Jul 1999 17:26:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA82339; Tue, 13 Jul 1999 17:25:21 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 17:25:21 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140025.RAA82339@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> <199907140004.JAA15623@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message