Re: NT vulnerable to attack on CPU

bofh@snoopy.virtual.net.au
Thu, 26 Dec 96 22:02:48 +1000


>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