lkml.org 
[lkml]   [1996]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NT vulnerable to attack on CPU

Hi,

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.
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.

Andi

At 14:00 26/12/96 +1000, bofh@snoopy.virtual.net.au wrote:
>>put a cronjob to run a bomb and this won't have any effect.
>>ie. linux limits (and prolly most unicees) are useless.
>>I'm prolly going to hack the kernel a bit to do the following:
>>certain limit for uid's < 1000
>>and certain limit for uid's > 1000 (users)
>
> 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).
>
> What do you think?
>
>
>Russell Coker
>
>

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.044 / U:9.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site