How can we deal with vandalism?20 responses total.
Is it possible to put a limit on the percentage of cpu time used by a single process (say 5%?) or the number of times a single process can be run at one time? I would suggest exempting a few basic processes like bash. Also can we restrict the number of logins from one source at one time?
What source do you mean? As in an IP limit? Or something tracing back further than the stop just prior to Grex? I can see either of the above being really problematic- and not necessarily helping decrease vandalism. And I have no idea if process size can be limited.
Some way to keep the same vandal from logging in multiple times under different names (or even under the same name). Then restricting the number of times a process can be run each time someone logs in. The most recent vandal was running the same process at least 20 times, probably 50-100. If you restrict a process to 5% of cpu time that will not help if someone runs in 20 times at the same time. The previous vandal was running one process that took up 98% of cpu time. How would you suggest blocking this sort of vandalism?
The easiest thing is to get Robocop back up and running. Jan is working on that, but it's taking a bit of time; the old version was highly turned to the environment of the Sun, and grex is now much different in terms of its internal structure.
How does robocop work? And until it works again, what is the best way to notify someone who can quickly deal with vandalism, if not emailing staff@grex.org?
E-mail staff@grex.org and be patient. Staff deals with things as quickly as they can. Sometimes, that won't be very quickly at all.
Vandals are nothing new on Grex. As an open system, the founders had the idea what we needed to be secure as people would be beating on us. I think we underestimated the amount of beating that would go on, but still, we've done very well over the years. If we want to stop the vandals we have to close all of Grex's open aspects, give a menu system to do things and probably eliminate email. I don't think thats what Grex is. It is definitely the case that 99%+ of the vandals now have little idea of what they are doing, and often can be seen bringing over programs for the wrong OS or machine type, etc. We have various tools to help out, and OpenBSD is really second to none in terms of security.
I disagree. Plan 9 is more secure, but probably because it's a system that's an order of magnitude smaller and is worked on by a much more talented group of people than OpenBSD. C'est la vie.
How would Robocop have stopped the recent vandalism?
Robocop looks for users using excessive amounts of any given resource (memory, CPU, etc) and kills all his processes.
Has plan9 been audited the way OpenBSD has? I don't think so, from what I've read of it. The continuing, relentless anal checking of things over and over again is one of the great points about this op system. Perhaps there are other groups doing this on other platforms, but I haven't heard about it.
(I thought that Plan 9 was mainly good for generating papers about operating systems. ;-)
I'm sorry, but I'm really not all that impressed by the `auditing' done by the OpenBSD people. The code rewriting they do just isn't that good.
Wasn't Plan 9 written, like, in outer space? ;-)
Heh. That sounds like an interesting discussion item in garage or somewhere else like that, Dan.
Regarding #14; By Ed Wood. Regarding #15; Fair enough.
Many of the vandal problems we've seen recently would have been trapped and killed by robocop on the old Grex. I have ported robocop to the new Grex, but it needs more debugging and tuning. Right now it has a holster full of blanks. It only logs problem users instead of killing them. I need to do more work on it before it is ready for live ammo.
Sindi, up until just now I would have been all for limiting the use of resources (I was thinking of suggesting that the use of "lynx" be banned - if someone can telnet to Grex surely they can browse from their own system more easily). However, while playing nethack, I got sick of the poor I/O so I logged in again and ran top to see if I could see anything that could account for the poor I/O. The result was nothing. What was odd was that while once seesion appeared to be hung the other worked just fine and vice versa. So I can only conclude that its a hardware issue with either the NIC or the cable modem. Does netstat report any network problems, for example?
I dial in to grex and use links and lynx. If I telnet instead there is often a lot of lag. Lynx is much faster at grex than it is over my modem. Have you tried dialing in to grex and playing nethack? I find there are more sudden freeze-ups during a telnet than a dialin.
TROGG IS DAVID BLAINE
You have several choices: