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

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

That quickly gets rather complicated for the task it does.
Something that complicated should do much more:

I remember talk of per-user data structures. They solve some problems
that are difficult now. For example, it may be OK for a user to run
a 16 MB process. It may be OK for a user to run 32 processes. That
does not mean it is OK to run 32 of those 16 MB processes!

Some sort of security daemon could load user limits into the kernel
as each UID is first used. The kernel could dispose of the per-UID
information as soon as the count of processes with a particular UID
reaches zero. Those system admins that don't need detailed user
control could just skip the daemon, which would make the kernel use
defaults. (something hacked info/from kerneld?)

There may be more uses than just user limits.

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