Messages in this thread |  | | From | bofh@snoopy ... | Date | Thu, 26 Dec 96 22:02:48 +1000 | Subject | Re: NT vulnerable to attack on CPU |
| |
>I think the way you think to implement it is far superior that what I thought >of. My knowledge of the kernel isn't good enough to do it with /proc so maybe >I'll wait until you get around to it.
My knowledge isn't yet good enough to do it. I plan to learn...
>I don't think you need to seperate staff. >On my machine for example staff is uid's <1000 so what should be done is to >echo "1000" > /proc/blah and maybe echo "64" > /proc/blah_proccessesallowed >You can always hard & soft limit proccesses for staff later on with regular >limits. SO there are ways with crontab etc.. to get around them but I don't >expect most of my staff to try and bomb the system. If they will they won't be >staff anymore.
That principle seems logical, but from experience I've found that things don't always work out that well. The only bombs I've come across (apart from the programs I've written to test how my system stands up to attack) have come from reliable trusted people who have made mistakes. During my time at Uni I accidentally brought down 2 time-sharing systems through buggy programs that ended up as rabbit processes (I know that I was a more capable C programmer than most students and I had no intention of harming the computers - I was just unlucky in the types of bugs in my code). At my ISP I implemented lshell because of staff crashing minicom and then leaving it running and taking all CPU time. They weren't trying to harm the system, they just weren't experienced enough with UNIX to notice and stop rogue programs. The reason for giving staff a larger quota of processes than users is because they genuinely need more. However much I trust them not to sabotage the system I can't trust them not to make mistakes.
>> I've been thinking of doing a similar hack. However what I would do is put >>some files under /proc/sys to specify the UID number that differentiates >system >>processes from user processes (it's UID 100 on my systems but other people >will >>have different numbers) and to specify the number of processes for users (it >>would be a PITA if you hard-coded this into the kernel and then installed a >>program which couldn't run properly without the number being increased). >> Another thing I've been thinking about is the possibility of adding more >>classes of users. EG Staff could be allowed to run more processes than >average >>users, but we still need some limits (can't give them no limits as we do with >>system UIDs).
Russell Coker
|  |