Re: How a normal user can crash any linux system (fwd)
/etc/security/limits.conf mmm... this is for pam_limits.so in linux has anyone ported it to BSD? -- mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
On Thu, Mar 23, 2000 at 10:01:33AM +0100, Egervary Gergely wrote: has anyone ported it to BSD? /etc/login.conf can set limits for you, in a possibly more flexable way. but login does not support session accounting that pam_limits.so does. I don't see anything about session accouning in the pam_limits section of the html docs distributed with Redhat (this doesn't mean they're not present though ;-) What exactly does it do? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
I don't see anything about session accouning in the pam_limits section of the html docs distributed with Redhat (this doesn't mean they're not present though ;-) What exactly does it do? for example, this is very important on a ppp dial-up server: $ grep maxlogins /etc/security/limits.conf @dialup hardmaxlogins 1 -- mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How a normal user can crash any linux system (fwd)
anybody want to try this on -current? ron -- Forwarded message -- Date: Wed, 22 Mar 2000 16:02:40 +0100 From: Michael Lampe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: How a normal user can crash any linux system I found the following by accident playing with PVM. If you start the 'gexample' from the examples directory with dimension=1 and no of tasks=32 on one machine, it becomes almost immediately completely un- usable and begins with heavy swapping. Considering how much memory would be necessary for this computation before starting it would have avoided the trouble. So the processes go on allocating memory until physical memory and swap is exhausted. At this point processes are killed and now things are really becoming interesting: One would expect that the misbehaving gexample processes are killed or maybe other processes started by the same user. Actually random processes are killed: I've seen klogd, syslogd, cron, gpm and inetd disappear. In some cases the machine was unaccessible locally as well as remotely, but the kernel seemed to be still running -- ping showed the machine still up. Apart from the specific system processes that are killed, the problem can be reproduced under many different configurations. I have tried SuSE 6.0 with kernel 2.2.12, SuSE 6.2 with kernel 2.2.14, LinuxPPC R4/R5 (Red Hat 5.x based) with some recent 2.2.x kernels and finally the SuSE pre-release for PPC. PVM was 3.4.x. Any comments - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
In reply: This is cross-posted to both linux-kernel and freebsd-hackers, please set your replies properly. I found the following by accident playing with PVM. If you start the 'gexample' from the examples directory with dimension=1 and no of tasks=32 on one machine, it becomes almost immediately completely un- usable and begins with heavy swapping. Considering how much memory would be necessary for this computation before starting it would have avoided the trouble. well, there are other ways to make a system slow to a crawl a good preventative measure is to never give shell accounts unless everyone is accountable. #!/bin/csh /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null # etc, ... # # [get the idea?] jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" -- [EMAIL PROTECTED] KC5VDJ - HF to 23cm KC5VDJ@NW0I.#NEKS.KS.USA.NOAM HF/VHF: IC-706MkII VHF/UHF/SHF: IC-T81AKPC3+ PK-232MBXGrid: EM28px -- ET has one helluva sense of humor, always anal-probing right-wing schizos! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
* Jim Bryant [EMAIL PROTECTED] [000322 14:19] wrote: In reply: This is cross-posted to both linux-kernel and freebsd-hackers, please set your replies properly. I found the following by accident playing with PVM. If you start the 'gexample' from the examples directory with dimension=1 and no of tasks=32 on one machine, it becomes almost immediately completely un- usable and begins with heavy swapping. Considering how much memory would be necessary for this computation before starting it would have avoided the trouble. well, there are other ways to make a system slow to a crawl a good preventative measure is to never give shell accounts unless everyone is accountable. True. #!/bin/csh /usr/games/primes 1 4294967295 /dev/null /usr/games/primes 1 4294967295 /dev/null # etc, ... # # [get the idea?] why are you 'scripting' in csh? eww. No i don't get the idea, login.conf in FreeBSD is able to limit a user to a maximum amount of processes, I think even cputime limitations work but I haven't tried them. Yes, and one shouldn't give accounts out to irresponcible/thoughtless people. 'rmuser' is your friend. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
:In reply: : This is cross-posted to both linux-kernel and freebsd-hackers, please : set your replies properly. : : I found the following by accident playing with PVM. If you start the : 'gexample' from the examples directory with dimension=1 and no of : tasks=32 on one machine, it becomes almost immediately completely un- : usable and begins with heavy swapping. Considering how much memory : would be necessary for this computation before starting it would have : avoided the trouble. : :well, there are other ways to make a system slow to a crawl : :a good preventative measure is to never give shell accounts unless :everyone is accountable. : :#!/bin/csh :/usr/games/primes 1 4294967295 /dev/null :/usr/games/primes 1 4294967295 /dev/null :/usr/games/primes 1 4294967295 /dev/null :... Generally speaking if a user wants to crash a machine, he can crash a machine. We've probably 'fixed' a dozen crashability holes in the last year but the count comes from a virtually unlimited supply. Short of being ridiculously draconian there will always be a way to twist the resource limits you are given to take a machine down or DOS it into unusability. And resource limits do not cover every conceivable facet. For example, just before the 4.0 release it was found that one can easily run the kernel out of vm_map_entry resources by mmap()ing hundreds of thousands of tiny files. We added a vm.max_proc_mmap sysctl to control that. And it still quite easy to bypass the datasize resource limit through the use of MAP_ANON mmap's. What resource limits are good at doing is preventing 'stupid user' mistakes. For example, at BEST we capped the CGI exec time at 10 cpu seconds (else our web servers would build up hundreds of broken CGI processes), but we set it as a soft limit so users who know what they are doing can unlimit it. I imposed a 40 process and 64 descriptor limit as being reasonable, but that's still 2560 descriptors to a user trying to mess things up on purpose. Quotas are useful for preventing a user from accidently filling up a disk partition. For example, I had a 100MB quota on /tmp, but quotas can be bypassed in a number of ways - for example, excessive syslogging (log files are owned by root). Resource limits are useful for protecting against a purposeful DOS attack insofar as it is generally the script kiddies who don't know their asses from their fingers who are trying to crash the machines. There is no way to protect against someone who knows what they are doing. So, in conclusion, resource limits are absolutely necessary in keeping a multi-user machine running smoothly, but the necessity has virtually nothing to do with preventing purposeful attacks. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
On Wed, 22 Mar 2000, Jim Bryant wrote: well, there are other ways to make a system slow to a crawl #!/bin/csh /usr/games/primes 1 4294967295 /dev/null [...] /etc/security/limits.conf get the idea? :) -Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How a normal user can crash any linux system (fwd)
This is cross-posted to both linux-kernel and freebsd-hackers, please set your replies properly. -- Forwarded message -- Date: Wed, 22 Mar 2000 16:02:40 +0100 From: Michael Lampe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: How a normal user can crash any linux system I found the following by accident playing with PVM. If you start the 'gexample' from the examples directory with dimension=1 and no of tasks=32 on one machine, it becomes almost immediately completely un- usable and begins with heavy swapping. Considering how much memory would be necessary for this computation before starting it would have avoided the trouble. So the processes go on allocating memory until physical memory and swap is exhausted. At this point processes are killed and now things are really becoming interesting: One would expect that the misbehaving gexample processes are killed or maybe other processes started by the same user. Actually random processes are killed: I've seen klogd, syslogd, cron, gpm and inetd disappear. In some cases the machine was unaccessible locally as well as remotely, but the kernel seemed to be still running -- ping showed the machine still up. Apart from the specific system processes that are killed, the problem can be reproduced under many different configurations. I have tried SuSE 6.0 with kernel 2.2.12, SuSE 6.2 with kernel 2.2.14, LinuxPPC R4/R5 (Red Hat 5.x based) with some recent 2.2.x kernels and finally the SuSE pre-release for PPC. PVM was 3.4.x. Any comments * Ronald G. Minnich [EMAIL PROTECTED] [000322 09:57] wrote: anybody want to try this on -current? No, a normal user shouldn't be able to crash any unix box with proper limits in place, this local DoS only works if there are no limitations. Please people, this is a 20 year old trick that I'm really tired of hearing come up every other month. It's called a forkbomb with a twist, it's old, boring and doesn't affect people with properly configured systems. Please consult your Operating System's documentation on how to setup limits. If you want to know why random processes are sometimes killed then you need to buy and read an OS book. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
