Re: DoS from local users (fwd)
A while ago on -current, I posted a reference to a paper on lottery scheduling in FreeBSD. It allows you to provide scheduling weightings that (on average) share the CPU as described. It is also used by the UC-Berkeley CSUA on their shell account machines. http://www.csua.berkeley.edu:80/computing/software/lottery-sched.html -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Chris Costello wrote: If one can't control one's users, one has no business managing them. The last thing FreeBSD needs is some overly complex, sophisticated scheduler designed to help bozo sysops stay on their feet. I agree with you very much here. Public shell systems are a bad idea. In my opinion, you should trust someone before you allow them to have an account on your system. What you really mean is that FreeBSD is not a solution for public shell systems, correct? Public shell systems is not a bad idea, it's a business opportunity and a public service. If the OS is not up to the task, don't blame the task. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
What you really mean is that FreeBSD is not a solution for public shell systems, correct? Public shell systems is not a bad idea, it's a business opportunity and a public service. If the OS is not up to the task, don't blame the task. Any Unix OS is going to give you more or less the same out-of-box experience for shell users, the real difference being in the administrators who manage the machine(s). For shell machines especially, the admin simply has to have a reasonably high level of clue or they can count on a world of grief from their own users, and I don't care if the box in question is running Linux, FreeBSD or Solaris. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Tue, Apr 13, 1999, Daniel C. Sobral wrote: What you really mean is that FreeBSD is not a solution for public shell systems, correct? Public shell systems is not a bad idea, it's a business opportunity and a public service. If the OS is not up to the task, don't blame the task. If you close your eyes and run towards a brick wall with the goal being to destroy it, and instead you injure yourself, it's not your forehead's fault or the wall's fault (no matter how much you cuss out the wall), but the person behind it. If you were strong and determined enough, perhaps you could solve the problem, but your forehead wasn't meant to crash through walls by default, and the brick wall wasn't meant to have a forehead plow through it. Make any sense? The admin shouldn't expect a public shell service to be secure out of the box with anything. BSD/OS, Linux, FreeBSD, NetBSD, OpenBSD - are any of these born shell service OS? I doubt it. It takes a hefty bit of 'tweaking', I'd imagine, to make a system fit to run a public shell. In theory, no OS I've heard of is a solution for shell systems, at least out of the box and with an unexperienced administrator. Does this clear it up? -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics -- Chris Costelloch...@calldei.com Be careful when a loop exits to the same place from side and bottom. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
:What you really mean is that FreeBSD is not a solution for public :shell systems, correct? Public shell systems is not a bad idea, :it's a business opportunity and a public service. If the OS is not :up to the task, don't blame the task. : :-- :Daniel C. Sobral (8-DCS) I would note that BEST.COM has been running, effectively, public shell systems for 5 years. The last couple of years have been using FreeBSD. It works just dandy. We put 2000 users on each box. Just because people aren't willing to spend thousands of hours making the kernel handle every conceivable user abuse doesn't make the machine a bad solution for a particular problem. With that sort of attitude, no operating system ever made could live up to your standards. FreeBSD does the things most easily handled in a kernel. You, the sysop, are supposed to do the things that are most easily handled by a sysop. That is inclusive of writing monitoring and kill scripts. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Matthew Dillon wrote: I would note that BEST.COM has been running, effectively, public shell systems for 5 years. The last couple of years have been using FreeBSD. It works just dandy. We put 2000 users on each box. Just because people aren't willing to spend thousands of hours making the kernel handle every conceivable user abuse doesn't make the machine a bad solution for a particular problem. With that sort of attitude, no operating system ever made could live up to your standards. FreeBSD does the things most easily handled in a kernel. You, the sysop, are supposed to do the things that are most easily handled by a sysop. That is inclusive of writing monitoring and kill scripts. Ok, disclaimer in the vain attempt to prevent further replies. I took an issue with blaming public shell accounts for perceived problems with the way FreeBSD manages them. I do think FreeBSD, and Unix, generally speaking, is one of the best deals available. It could be improved, and it does require non-clueless sysadmins. Saying public shell accounts are a bad idea is dismissing the real issues, and blaming the messenger for the bad news. What you, Dillon, were saying in the message quoted in the message I originally replied to, is to the point. FreeBSD can handle it, as long as the sysadmin knows what s/he is doing. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Chris Costello once stated: =On Sat, Apr 10, 1999, Matthew Dillon wrote: = :Sun has a product for this, Solaris Resource Manager. = You don't need to tune user accounts, you need only put the =users in a separate login class (if that hasn't already been =done) and modify the resource limitation for that login =restriction. Speaking of which. Can we have the login class database distributed over NIS? = If one can't control one's users, one has no business managing = them. The last thing FreeBSD needs is some overly complex, = sophisticated scheduler designed to help bozo sysops stay on = their feet. = I agree with you very much here. Public shell systems are a =bad idea. In my opinion, you should trust someone before you =allow them to have an account on your system. Can we, perhaps, have a configurable maximum load level for each class? The users of the class will not be allowed to start new processes if the current load is above that number? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Just review the thread: . Look, here is a little script, which allows any user to perform a DoS attack! . Khmm, yes indeed, but you can remove any user who does this. . But shouldn't the system be able to sustain/detect this sort of attack? [... Nice theoretical discussion is skipped. ...] . No, it is your responsibility as a sysop, do not give accounts to those you don't trust. . Oh, well, but what about public-shell systems? . Public shell systems are a bad idea! . Just because FreeBSD can not handle it, does not mean the task itself is a bad idea... . [Now we are all upset, flames start to light the sky]: . FreeBSD handles this here and here! . No OS will handle it quite right... . You just need to be a better sysop. . Sorry, no offense meant... Why don't we admit this possibility exists (as well as many others, perhaps) for a local user to cause a DoS and may be someday someone will address it? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
In message 199904131256.iaa08...@kot.ne.mediaone.net, Mikhail Teterin writes: Why don't we admit this possibility exists (as well as many others, perhaps) for a local user to cause a DoS and may be someday someone will address it? Because we have (counts for a moment, but as he flips to the third page of notes sighs deeply and gives up) more than plenty of things we need to do before that becomes the top priority problem... -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Kevin Day wrote: On the shell servers I run, we've got 200-300 users running tasks. Occasionally, through intent or misconfiguration, a user either forkbombs, or gets a large number of processes running sucking lots of cpu. I'd like to see an option that makes all the processes run by one uid have the same weight as one process another uid is running. i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's 40 processes get 50% cpu shared between them. This way, one errant user can't have as significant of an impact. Is this plausable? A while ago on -current, I posted a reference to a paper on lottery scheduling in FreeBSD. It allows you to provide scheduling weightings that (on average) share the CPU as described. Do a search of the -current or -hackers archive and it should show up. If not, let me know and I can dig up the reference. I believe it was a section of a CMU Tech Report. I don't know what the source code availability of that is, but it presumably was a month-long project for two grad students or something, so should be quite feasible. However, because processes in kernel mode are non-preemptible, it is impossible to deal with some of the connotations of a hog process. But because these processes are billed for some of the resources they consume in kernel mode (i.e., the CPU spent by their kernel thread), at least that can be taken into account. Matt makes the excellent point in another email that once you have this facility, you need to make sure that your CPU policy actually reflects what you want: do you want some process to displace some other process for fairness when fairness impedes throughput in such a way that you might be denying something else service because that something else cannot be represented in the scheduling policy? A combination of priorities and lottery tickets might be the best solution. Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Poul-Henning Kamp once stated: =Why don't we admit this possibility exists (as well as many others, =perhaps) for a local user to cause a DoS and may be someday someone =will address it? =Because we have (counts for a moment, but as he flips to the third =page of notes sighs deeply and gives up) more than plenty of things =we need to do before that becomes the top priority problem... Ok. So, make this the (n+1)th on the list... Why is somebody saying FreeBSD can not do this gets flamed with other OSes can not either or OS is not supposed to do this? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
In message 199904131325.jaa08...@kot.ne.mediaone.net, Mikhail Teterin writes: Poul-Henning Kamp once stated: =Why don't we admit this possibility exists (as well as many others, =perhaps) for a local user to cause a DoS and may be someday someone =will address it? =Because we have (counts for a moment, but as he flips to the third =page of notes sighs deeply and gives up) more than plenty of things =we need to do before that becomes the top priority problem... Ok. So, make this the (n+1)th on the list... Why is somebody saying FreeBSD can not do this gets flamed with other OSes can not either or OS is not supposed to do this? Because people would rather be hacking code than arguing fine points of irrellevant theoretical issues ? Please let this thread die now. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: DoS from local users (fwd)
-Original Message- From: Amancio Hasty [SMTP:ha...@rah.star-gate.com] Sent: Sunday, April 11, 1999 5:36 AM To: Matthew Dillon Cc: Dmitry Valdov; Brian Feldman; freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) I guess any sufficiently advance science is indeed consider magic by some. Amancio [ML] Then I would like to have a high-tech gizmo for reading my users' minds. Would you, perhaps, know where I could buy/borrow/steal one of these? :) /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Warner Losh i...@harmony.village.org writes: In message 199904102057.paa27...@home.dragondata.com Kevin Day writes: : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's : 40 processes get 50% cpu shared between them. I've seen some experimental patches in the past that try to do just this. However, there are some problems. What if uid 1002's process does a sleep. Should the 40 processes that 1001 just get 50% of the cpu? Or should there be other limits. It turns into an interesting research problem in a hurry. That's a simple matter of implementation decisions. Naturally there's hardly ever a good reason to keep a processor idle, so the limits should only apply when the processor would not otherwise be idle. How this affects the amount of runtime the processes get later depends on how you compute percentages. An example approach is what the class scheduling feature in Digital UNIX does. I'll describe it from what I remember from playing with it a couple of years ago, so all of this is only true IIRC. It has some fixed scheduling period, for which it allocates cycles for that period to scheduling classes (threads, users, groups, whatever) based on the percentage limits. The only addition to the scheduler is having threads consume these cycles from the scheduling classes. When those cycles have been used up, threads in that class are not allowed to run. If an eligible processor would otherwise be idle, they may be allowed to run despite this (the behavior is configurable in some scope, I can't remember whether it was global or per class). The class scheduler in Digital UNIX is, in many respects, a kludge, and I'm not recommending that FreeBSD implement a similar mechanism. But it is semantically sane, and unlikely to cause additional problems when configured with reasonable parameters. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
: What was their user name again? : *click xterm click* : ps aux | grep ^user | wc -l : Hmm, you're right, fifty processes called 'cpuwaster'. : rmuser user : They've been eliminated, thank you for letting us know of problems you have! : : It's called being a sysadmin. If someone's abusing the machine, delete em. [ Redirected to chat ] There are several points which I would like to make in response to this posting. 1) cpuwaster may be solving a significant problem. One man's cpuwaster is another man's breadandbutter. 2) Adding useful new scheduling policy options to the system allows a good sysadmin to be a better sysadmin. That's a Good Thing. 3) One man's sysadmin is another man's asshole. (Made you think, didn't I?) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, Apr 10, 1999, Matthew Dillon wrote: :Sun has a product for this, Solaris Resource Manager. ... and if one user is *supposed* to be running all those processes, then what? Oh, let me guess: Now you are supposed to tune each user's account independantly. For a system with general user accounts, this is a burden on the sysop. You don't need to tune user accounts, you need only put the users in a separate login class (if that hasn't already been done) and modify the resource limitation for that login restriction. If one can't control one's users, one has no business managing them. The last thing FreeBSD needs is some overly complex, sophisticated scheduler designed to help bozo sysops stay on their feet. I agree with you very much here. Public shell systems are a bad idea. In my opinion, you should trust someone before you allow them to have an account on your system. -Matt Matthew Dillon dil...@backplane.com -- Chris Costelloch...@calldei.com Computers talk to each other worse than their designers do. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Amancio Hasty wrote: It should be possible to prevent a user from hogging a system if the system's naive scheduler is improved. I think the problem is not related to the scheduler, but to the code path involved in running and reading the file at the same time, multiple times. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
In message 199904102057.paa27...@home.dragondata.com Kevin Day writes: : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's : 40 processes get 50% cpu shared between them. I've seen some experimental patches in the past that try to do just this. However, there are some problems. What if uid 1002's process does a sleep. Should the 40 processes that 1001 just get 50% of the cpu? Or should there be other limits. It turns into an interesting research problem in a hurry. Warner I was thinking essentially just processes in the RUN state get applied to this. If the cpu would otherwise be sitting idle, by all means give it to someone. But, if two users have processes running, just because one user has 50 processes doesn't mean it should get 50x the cpu as one user who has one process running. If a process is in sleep or blocked(select, IO, whatever), it's taken out of consideration for the cpu, and the full cpu is given to those processes that actually have work to do. At least, that's my take on it. I run into this problem daily, and i get enough user complains of User x has 50 processes running, eating as much cpu as they can, my compile just took 15 minutes. Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
In message 37106b7d.50b2f...@rcc.on.ca Rod Taylor writes: : I like this, but the problem with that fork bomb program still exists. : It was afterall system cpu that was doing all the work, not the users : cpu. System CPU still gets charged to the user, so this is a non-issue. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
In message 199904102057.paa27...@home.dragondata.com Kevin Day writes: : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's : 40 processes get 50% cpu shared between them. I've seen some experimental patches in the past that try to do just this. However, there are some problems. What if uid 1002's process does a sleep. Should the 40 processes that 1001 just get 50% of the cpu? Or should there be other limits. It turns into an interesting research problem in a hurry. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sun, 11 Apr 1999, Kevin Day wrote: In message 199904102057.paa27...@home.dragondata.com Kevin Day writes: : i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid : 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's : 40 processes get 50% cpu shared between them. I've seen some experimental patches in the past that try to do just this. However, there are some problems. What if uid 1002's process does a sleep. Should the 40 processes that 1001 just get 50% of the cpu? Or should there be other limits. It turns into an interesting research problem in a hurry. Warner I was thinking essentially just processes in the RUN state get applied to this. If the cpu would otherwise be sitting idle, by all means give it to someone. But, if two users have processes running, just because one user has 50 processes doesn't mean it should get 50x the cpu as one user who has one process running. If a process is in sleep or blocked(select, IO, whatever), it's taken out of consideration for the cpu, and the full cpu is given to those processes that actually have work to do. At least, that's my take on it. I run into this problem daily, and i get enough user complains of User x has 50 processes running, eating as much cpu as they can, my compile just took 15 minutes. What was their user name again? *click xterm click* ps aux | grep ^user | wc -l Hmm, you're right, fifty processes called 'cpuwaster'. rmuser user They've been eliminated, thank you for letting us know of problems you have! It's called being a sysadmin. If someone's abusing the machine, delete em. Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Mikhail Teterin wrote: What about a new login-class capability specifying the maximum percentage of CPU time a class of users can utilize? With standard class having 90% (or 95%)? The machine would appear (to most of the users) as if it had 10% slower CPU, with the remaining usable by the root-class. This way, if the CPU consumption by system is 30%, the most CPU time the standard users can get is 60%. Trusted users can be placed into a different class, of course. Plausible? What you guys are describing is the FAIR SHARE scheduler for Unix, as implemented by Softway in Sydney many years ago. It originated in Sydney University as part of the efforsts of the CS department there to share out an old Vax 11/780 amongst 80 odd users at a time. Students aren't noted for their common sense, so measures like this were necessary. Stephen -- The views expressed above are not those of PGS Tensor. We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true.Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Fri, 9 Apr 1999, Chris Costello wrote: Date: Fri, 9 Apr 1999 18:30:31 -0500 From: Chris Costello ch...@holly.dyndns.org Reply-To: ch...@calldei.com To: Dmitry Valdov d...@dv.ru Cc: freebsd-questi...@freebsd.org Subject: Re: DoS from local users On Fri, Apr 9, 1999, Dmitry Valdov wrote: Hi! Try it: cat qqq echo $$ echo ~/qqq|~/qqq|~/qqq|~/qqq|~/qqq Ctrl-D ./qqq Is there Any way to fix it? You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, Apr 10, 1999, Dmitry Valdov wrote: You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. How is it a kernel problem? It's a forkbomb. It spawns many processes. You can also limit CPU usage with login.conf, I believe. Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- === * Using TSO is like kicking a dead whale down the * * beach. -- S. C. Johnson * === To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Chris Costello wrote: Date: Sat, 10 Apr 1999 02:05:33 -0500 From: Chris Costello ch...@holly.dyndns.org Reply-To: ch...@calldei.com To: Dmitry Valdov d...@dv.ru Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, Apr 10, 1999, Dmitry Valdov wrote: You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. How is it a kernel problem? It's a forkbomb. It spawns many processes. You can also limit CPU usage with login.conf, I believe. Hmm. How I can limit CPU usage by SYSTEM? See top's output below. Dmitry. PS. I've just tried it. And I'm right - CPU usage limit can't help. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Dmitry Valdov wrote: On Sat, 10 Apr 1999, Chris Costello wrote: Date: Sat, 10 Apr 1999 02:05:33 -0500 From: Chris Costello ch...@holly.dyndns.org Reply-To: ch...@calldei.com To: Dmitry Valdov d...@dv.ru Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, Apr 10, 1999, Dmitry Valdov wrote: You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. How is it a kernel problem? It's a forkbomb. It spawns many processes. You can also limit CPU usage with login.conf, I believe. Hmm. How I can limit CPU usage by SYSTEM? See top's output below. Dmitry. PS. I've just tried it. And I'm right - CPU usage limit can't help. So? Processes that run a while go down in priority [McKusick95 I believe, THE book] so they are preempted easily. Look in top and see if they're all at the top of the list. I bet they're not! Also, you can set per-user niceness levels, and why are you being so liberal giving a standard LUSER 32 processes? This is a system administration problem. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Hi! Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just tried set maxprocesses 5. And it helpless. With 5 processes limit user was able to slow down P2-450 computer. Switching between windows in X was VERY slow. Mouse movements was slow down too. CPU states: 32.3% user, 0.0% nice, 67.2% system, 0.0% interrupt, 0.5% idle Please, just try it. On Sat, 10 Apr 1999, Brian Feldman wrote: Date: Sat, 10 Apr 1999 09:29:19 -0400 (EDT) From: Brian Feldman gr...@unixhelp.org To: Dmitry Valdov d...@dv.ru Cc: ch...@calldei.com, freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, 10 Apr 1999, Dmitry Valdov wrote: On Sat, 10 Apr 1999, Chris Costello wrote: Date: Sat, 10 Apr 1999 02:05:33 -0500 From: Chris Costello ch...@holly.dyndns.org Reply-To: ch...@calldei.com To: Dmitry Valdov d...@dv.ru Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, Apr 10, 1999, Dmitry Valdov wrote: You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. How is it a kernel problem? It's a forkbomb. It spawns many processes. You can also limit CPU usage with login.conf, I believe. Hmm. How I can limit CPU usage by SYSTEM? See top's output below. Dmitry. PS. I've just tried it. And I'm right - CPU usage limit can't help. So? Processes that run a while go down in priority [McKusick95 I believe, THE book] so they are preempted easily. Look in top and see if they're all at the top of the list. I bet they're not! Also, you can set per-user niceness levels, and why are you being so liberal giving a standard LUSER 32 processes? This is a system administration problem. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Dmitry Valdov once stated: =Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just =tried set maxprocesses 5. And it helpless. With 5 processes limit user =was able to slow down P2-450 computer. Switching between windows in X =was VERY slow. Mouse movements was slow down too. =CPU states: 32.3% user, 0.0% nice, 67.2% system, 0.0% interrupt, 0.5% idle Obviously, it is not the CPU consumed by the user processes, but mostly by the system, which spends time spawning them, counting them, and refusing to spawn any more. And a normal user can ligitimately need more then 32 processes, say for your average X-session -- with all the terms, biffs, clocks, screensaver, etc. Would be nice to see some sort of per-user kernel CPU-time limit... -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Dmitry Valdov wrote: Hi! Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just tried set maxprocesses 5. And it helpless. With 5 processes limit user was able to slow down P2-450 computer. Switching between windows in X was VERY slow. Mouse movements was slow down too. CPU states: 32.3% user, 0.0% nice, 67.2% system, 0.0% interrupt, 0.5% idle Please, just try it. If you want to preempt other tasks, make that user's tasks niced!! On Sat, 10 Apr 1999, Brian Feldman wrote: Date: Sat, 10 Apr 1999 09:29:19 -0400 (EDT) From: Brian Feldman gr...@unixhelp.org To: Dmitry Valdov d...@dv.ru Cc: ch...@calldei.com, freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, 10 Apr 1999, Dmitry Valdov wrote: On Sat, 10 Apr 1999, Chris Costello wrote: Date: Sat, 10 Apr 1999 02:05:33 -0500 From: Chris Costello ch...@holly.dyndns.org Reply-To: ch...@calldei.com To: Dmitry Valdov d...@dv.ru Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, Apr 10, 1999, Dmitry Valdov wrote: You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. How is it a kernel problem? It's a forkbomb. It spawns many processes. You can also limit CPU usage with login.conf, I believe. Hmm. How I can limit CPU usage by SYSTEM? See top's output below. Dmitry. PS. I've just tried it. And I'm right - CPU usage limit can't help. So? Processes that run a while go down in priority [McKusick95 I believe, THE book] so they are preempted easily. Look in top and see if they're all at the top of the list. I bet they're not! Also, you can set per-user niceness levels, and why are you being so liberal giving a standard LUSER 32 processes? This is a system administration problem. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Brian Feldman once stated: = Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just = tried set maxprocesses 5. And it helpless. With 5 processes limit = user was able to slow down P2-450 computer. Switching between windows = in X was VERY slow. Mouse movements was slow down too. = CPU states: 32.3% user, 0.0% nice, 67.2% system, 0.0% interrupt, 0.5% idle =If you want to preempt other tasks, make that user's tasks niced!! Which user? You don't know until it happens... And the mentioned already baseball bat is more effective _after_ the fact. The question is, is it possible to prevent this from happening in the first place, without quering the Human Resources department for each user's mental profile?.. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Brian Feldman wrote: Date: Sat, 10 Apr 1999 14:07:27 -0400 (EDT) From: Brian Feldman gr...@unixhelp.org To: Dmitry Valdov d...@dv.ru Cc: freebsd-current@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, 10 Apr 1999, Dmitry Valdov wrote: Hi! Once again - HOW I can limit CPU usage by *kernel* ? Also, I've just tried set maxprocesses 5. And it helpless. With 5 processes limit user was able to slow down P2-450 computer. Switching between windows in X was VERY slow. Mouse movements was slow down too. CPU states: 32.3% user, 0.0% nice, 67.2% system, 0.0% interrupt, 0.5% idle Please, just try it. If you want to preempt other tasks, make that user's tasks niced!! Have You tried it? Please try. I think that it's a system call problem. When (pipe, exec, or something? I dont' known how it syscall named) is called many times at the same time, kernel starts using all CPU time while performing these syscalls. It's just my opinion. But I see no way to prevent users from overloading system by kernel. (hmmm, if not to limit maxproc to one or two ;- On Sat, 10 Apr 1999, Brian Feldman wrote: Date: Sat, 10 Apr 1999 09:29:19 -0400 (EDT) From: Brian Feldman gr...@unixhelp.org To: Dmitry Valdov d...@dv.ru Cc: ch...@calldei.com, freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, 10 Apr 1999, Dmitry Valdov wrote: On Sat, 10 Apr 1999, Chris Costello wrote: Date: Sat, 10 Apr 1999 02:05:33 -0500 From: Chris Costello ch...@holly.dyndns.org Reply-To: ch...@calldei.com To: Dmitry Valdov d...@dv.ru Cc: freebsd-current@FreeBSD.ORG, freebsd-questi...@freebsd.org Subject: Re: DoS from local users (fwd) On Sat, Apr 10, 1999, Dmitry Valdov wrote: You typically want to set a restriction as to how many processes a user can spawn. This is done by editing /etc/login.conf and changing the user's login class, see the man page for 'login.conf'. I'm about CPU usage, not about many processes. See: CPU states: 17.8% user, 0.0% nice, 81.7% system, 0.5% interrupt, 0.0% idle on any (tested on P2-45) machine. CPU is used by SYSTEM, not by USER. So I can't restrict it with login.conf And load average can be up to 20-40 :( Please don't redirect me to -questions, it's a kernel problem, not just config. How is it a kernel problem? It's a forkbomb. It spawns many processes. You can also limit CPU usage with login.conf, I believe. Hmm. How I can limit CPU usage by SYSTEM? See top's output below. Dmitry. PS. I've just tried it. And I'm right - CPU usage limit can't help. So? Processes that run a while go down in priority [McKusick95 I believe, THE book] so they are preempted easily. Look in top and see if they're all at the top of the list. I bet they're not! Also, you can set per-user niceness levels, and why are you being so liberal giving a standard LUSER 32 processes? This is a system administration problem. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \__ \ |) | http://www.freebsd.org _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
It is not possible to prevent a user from hogging the cpu on the system. What you *CAN* do is make it difficult for the user to crash the system by limiting the number of processes he is allowed to run, the maximum data segment size each process is allowed to allocate, and by placing quotas on disk partitions he has write access to. This allows a sysop to get on the system and blow the idiot user away without having to reboot. cpu utilization has nothing to do with system cpu verses user cpu. cpu is cpu. One process can hog the cpu, it doesn't really matter whether it is supervisor or user mode cpu. The system will attempt to balance cpu utilization when several processes need cpu. The worst a user can do cpu-wise is to start N cpu-bound processes. Starting N cpu-bound processes will drive the load up on the machine, but as long as N is limited it will not prevent a sysop from getting in there and taking out the user. You don't give user accounts away to people who you think might try to crash the system, so resource limits are mostly there to prevent users making stupid mistakes from taking the system down with them. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
It should be possible to prevent a user from hogging a system if the system's naive scheduler is improved. Amancio It is not possible to prevent a user from hogging the cpu on the system. What you *CAN* do is make it difficult for the user to crash the system by limiting the number of processes he is allowed to run, the maximum data segment size each process is allowed to allocate, and by placing quotas on disk partitions he has write access to. This allows a sysop to get on the system and blow the idiot user away without having to reboot. cpu utilization has nothing to do with system cpu verses user cpu. cpu is cpu. One process can hog the cpu, it doesn't really matter whether it is supervisor or user mode cpu. The system will attempt to balance cpu utilization when several processes need cpu. The worst a user can do cpu-wise is to start N cpu-bound processes. Starting N cpu-bound processes will drive the load up on the machine, but as long as N is limited it will not prevent a sysop from getting in there and taking out the user. You don't give user accounts away to people who you think might try to crash the system, so resource limits are mostly there to prevent users making stupid mistakes from taking the system down with them. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
: :It should be possible to prevent a user from hogging a system if the system's :naive scheduler is improved. : : Amancio No, it isn't. For a very simple reason: The resources users need to do real work are very similar to the resources users need to hog the system. Saying that the system should somehow be able to magically make the distinction between the two is a pipedream. It takes a human to make the distinction. Short of restricting the resources you give to users to the point where they can't even start a mail or news client, there is just no way to prevent said users from loading down the machine if they choose to. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Hello, Let's remember a motto of J. Pournelle of the late Byte : one User, more than one CPU (let people hog their workstation as much as they want ...) And another good resolution : no shell accounts for normal users on sensitive servers (no lusers which could want to DoS the servers allowed) Every base covered ? Cheers TfH Matthew Dillon wrote: : :It should be possible to prevent a user from hogging a system if the system's :naive scheduler is improved. : : Amancio No, it isn't. For a very simple reason: The resources users need to do real work are very similar to the resources users need to hog the system. Saying that the system should somehow be able to magically make the distinction between the two is a pipedream. It takes a human to make the distinction. Short of restricting the resources you give to users to the point where they can't even start a mail or news client, there is just no way to prevent said users from loading down the machine if they choose to. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
: :It should be possible to prevent a user from hogging a system if the system's :naive scheduler is improved. : : Amancio No, it isn't. For a very simple reason: The resources users need to do real work are very similar to the resources users need to hog the system. That has nothing to do with it. Not for cpu usage. If you have two users that are using all the CPU they can they ought to get 50% of the CPU each. Even if one of the users have 1 process and the other have 100 processes. Sun has a product for this, Solaris Resource Manager. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
: : No, it isn't. For a very simple reason: The resources users need to do : real work are very similar to the resources users need to hog the system. : :That has nothing to do with it. Not for cpu usage. If you have two users that :are using all the CPU they can they ought to get 50% of the CPU each. Even if :one of the users have 1 process and the other have 100 processes. : :Sun has a product for this, Solaris Resource Manager. ... and if one user is *supposed* to be running all those processes, then what? Oh, let me guess: Now you are supposed to tune each user's account independantly. For a system with general user accounts, this is a burden on the sysop. If one can't control one's users, one has no business managing them. The last thing FreeBSD needs is some overly complex, sophisticated scheduler designed to help bozo sysops stay on their feet. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
: :It should be possible to prevent a user from hogging a system if the system's :naive scheduler is improved. : : Amancio No, it isn't. For a very simple reason: The resources users need to do real work are very similar to the resources users need to hog the system. Saying that the system should somehow be able to magically make the distinction between the two is a pipedream. It takes a human to make the distinction. Short of restricting the resources you give to users to the point where they can't even start a mail or news client, there is just no way to prevent said users from loading down the machine if they choose to. -Matt On the shell servers I run, we've got 200-300 users running tasks. Occasionally, through intent or misconfiguration, a user either forkbombs, or gets a large number of processes running sucking lots of cpu. I'd like to see an option that makes all the processes run by one uid have the same weight as one process another uid is running. i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid 1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's 40 processes get 50% cpu shared between them. This way, one errant user can't have as significant of an impact. Is this plausable? Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
:On the shell servers I run, we've got 200-300 users running tasks. :Occasionally, through intent or misconfiguration, a user either forkbombs, :or gets a large number of processes running sucking lots of cpu. : :I'd like to see an option that makes all the processes run by one uid have :the same weight as one process another uid is running. : :i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid :1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's :40 processes get 50% cpu shared between them. : :This way, one errant user can't have as significant of an impact. : :Is this plausable? : :Kevin Plausable, yes. Useful: probably not as useful as you might think. I wouldn't even consider doing something like that for BEST, it could lead to cascade failures. For example, if a user is running procmail or cron on a relatively loaded system, the user's share of the cpu relative to other users might not be sufficient to handle the user's medium term mail and/or job load. If there are a few hundred users logged in, this could rapidly devolve into a cascade failure which fills the system's process table. This in turn can lockup sendmail's waiting to lock the user's mailbox which in turn can lead to a cascade failure with the root-run sendmails. Sometimes, the most noble of purposes can make a machine less stable in inobvious ways. In the above example, limitations on a user process might lead to a backup of root-run services. A user-run CGI is another example. Say you have a web server which runs CGI's under a user id. If the web site is loaded down and the user happens to run a log processing script, execs of the user's CGIs might slow down due to the load balancing 'feature'. The web server may now wind up in the situation where it is forking CGIs faster then it can retire them. Leading to another cascade failure. In general, it is best to treat process scheduling without taking into account other processes run by the same user. If a user misbehaves, the best solution is to stomp on him until he does behave, not try to shove the misbehavior under the run by making the system 'control' the user's resources. If you do not actively control the behavior of your users all you will accomplish is to have a large number of them misbehaving continuously rather then just one or two. The result is going to be the same: A loaded down server and lots of complaints. users, -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
:That has nothing to do with it. Not for cpu usage. If you have two users that :are using all the CPU they can they ought to get 50% of the CPU each. Even if :one of the users have 1 process and the other have 100 processes. : :Sun has a product for this, Solaris Resource Manager. ... and if one user is *supposed* to be running all those processes, then what? Oh, let me guess: Now you are supposed to tune each user's account independantly. For a system with general user accounts, this is a burden on the sysop. ? Then that user continue to run all those processes, but won't take a bigger share of the resources than any other user. This is not diffrent from one process not using all the CPU when there are other processes that need CPU. If one can't control one's users, one has no business managing them. The last thing FreeBSD needs is some overly complex, sophisticated scheduler designed to help bozo sysops stay on their feet. You can't manage users today as you don't have anyting good to control them with. We have that for processes, so you can manage processes. This helps for runaway daemons and things like that to. (The Web server gets 75% and the rest to the sql server for example). Is it worth the trouble to implement? Maybe not. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Matthew Dillon wrote: :Kevin Plausable, yes. Useful: probably not as useful as you might think. I wouldn't even consider doing something like that for BEST, it could lead to cascade failures. For example, if a user is running procmail or cron on a relatively loaded system, the user's share of the cpu relative to other users might not be sufficient to handle the user's medium term mail and/or job load. If there are a few hundred users logged in, this could rapidly devolve into a cascade failure which fills the system's process table. This in turn can lockup sendmail's waiting to lock the user's mailbox which in turn can lead to a cascade failure with the root-run sendmails. Sometimes, the most noble of purposes can make a machine less stable in inobvious ways. In the above example, limitations on a user process might lead to a backup of root-run services. A user-run CGI is another example. Say you have a web server which runs CGI's under a user id. If the web site is loaded down and the user happens to run a log processing script, execs of the user's CGIs might slow down due to the load balancing 'feature'. The web server may now wind up in the situation where it is forking CGIs faster then it can retire them. Leading to another cascade failure. In general, it is best to treat process scheduling without taking into account other processes run by the same user. If a user misbehaves, the best solution is to stomp on him until he does behave, not try to shove the misbehavior under the run by making the system 'control' the user's resources. If you do not actively control the behavior of your users all you will accomplish is to have a large number of them misbehaving continuously rather then just one or two. The result is going to be the same: A loaded down server and lots of complaints. users, Matt, I agree with what you're saying, but what would you think about something that would take a look at the total cpu time that a process group had accumulated in the previous 120 seconds. That would be, I think, plenty long enough to catch most inadvertent things, and just kill the process leader. You could allow some users to have very high limits, but an attacker, someone purposely bringing the machine down (a hacker) would find only 2 minute capabilities. Do you think something like this would still contribute to the cascade failure scenarios? -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
:Matt, I agree with what you're saying, but what would you think about :something that would take a look at the total cpu time that a process :group had accumulated in the previous 120 seconds. That would be, I :think, plenty long enough to catch most inadvertent things, and just :kill the process leader. You could allow some users to have very high :limits, but an attacker, someone purposely bringing the machine down (a :hacker) would find only 2 minute capabilities. : :Do you think something like this would still contribute to the cascade :failure scenarios? This would contribute to the number of complaints you receive from users about 'things getting killed at odd times'. Here you are assuming that users only run short-term cpu-intensive processes. This is, in fact, not true. For example, many BEST users run log processing scripts in the wee hours of the morning. These scripts are often cpu-intensive and can take as much as half an hour of cpu time before completing. While I instituted resource limits on BEST users, I had to make them relatively generous because BEST users often run things legally that eat a lot of resources. File descriptors ( log processing into breakdown files ), processes ( screen sessions ), memory ( tin, emacs ), cpu ( log processing, mailing list run, procmail ). Also, we do not want to penalize users when their accounts or web pages get attacked. If a user's web page is attacked, dozens of CGI's a second might be run on that user's behalf. The machine needs to be able to grin and brunt it while we go after the source of the attack to prevent the attacker from gaining his goal of disrupting that user. Which means: Even if you had such a mechanism, you would have to set *very* generous limits in order to avoid having it accidently kill a user's legitimate work. As I said, it really takes a human to figure out the difference between a mistake, a hack, or a valid operation. -Matt Matthew Dillon dil...@backplane.com :+--- :Chuck Robey | Interests include any kind of voice or data :chu...@picnic.mat.net | communications topic, C programming, and Unix. :213 Lakeside Drive Apt T-1 | :Greenbelt, MD 20770 | I run picnic (FreeBSD-current) :(301) 220-2114 | and jaunt (Solaris7). :+--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
On Sat, 10 Apr 1999, Matthew Dillon wrote: Date: Sat, 10 Apr 1999 14:08:41 -0700 (PDT) From: Matthew Dillon dil...@apollo.backplane.com To: Kevin Day toa...@home.dragondata.com Cc: ha...@rah.star-gate.com, d...@dv.ru, gr...@unixhelp.org, freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) A user-run CGI is another example. Say you have a web server which runs CGI's under a user id. If the web site is loaded down and the user happens to run a log processing script, execs of the user's CGIs might slow down due to the load balancing 'feature'. The web server may now wind up in the situation where it is forking CGIs faster then it can retire them. Leading to another cascade failure. Make it configurable then... Dmitry. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
I guess any sufficiently advance science is indeed consider magic by some. Amancio : :It should be possible to prevent a user from hogging a system if the system's :naive scheduler is improved. : : Amancio No, it isn't. For a very simple reason: The resources users need to do real work are very similar to the resources users need to hog the system. Saying that the system should somehow be able to magically make the distinction between the two is a pipedream. It takes a human to make the distinction. Short of restricting the resources you give to users to the point where they can't even start a mail or news client, there is just no way to prevent said users from loading down the machine if they choose to. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
What about a new login-class capability specifying the maximum percentage of CPU time a class of users can utilize? With standard class having 90% (or 95%)? The machine would appear (to most of the users) as if it had 10% slower CPU, with the remaining usable by the root-class. This way, if the CPU consumption by system is 30%, the most CPU time the standard users can get is 60%. Trusted users can be placed into a different class, of course. Plausible? -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DoS from local users (fwd)
Mikhail Teterin wrote: What about a new login-class capability specifying the maximum percentage of CPU time a class of users can utilize? With standard class having 90% (or 95%)? The machine would appear (to most of the users) as if it had 10% slower CPU, with the remaining usable by the root-class. This way, if the CPU consumption by system is 30%, the most CPU time the standard users can get is 60%. Trusted users can be placed into a different class, of course. Plausible? I like this, but the problem with that fork bomb program still exists. It was afterall system cpu that was doing all the work, not the users cpu. I can however see how this could be useful for even myself. People who want to run eggdrops can have 40% cpu max on my shell server ;) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
