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

>>>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 syste
>>m
>>processes from user processes (it's UID 100 on my systems but other people wil
>>l
>>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 averag
>>e
>>users, but we still need some limits (can't give them no limits as we do with
>>system UIDs).
>>
>> What do you think?

>Why not just setup something which is in some way connected to the existing
>file access groups? (You know, the stuff in /etc/group.)

There could be some scope for this. However a number of important design
questions have to be answered:

Do we use additional groups or just the GID of the process?
If we use additional groups do we use the most restrictive or the least
restrictive to set the policy? If we use additional groups then things could
become confusing when a user can start a process in one context but not in
another.

The option of "just setup something in /etc/groups" does not solve the
problem. If we base it on /etc/groups then we have to decide how to do so in
addition to the other issues I've already considered (how to tell the kernel to
start doing this and how many processes per group - probably through something
in /proc).

I think that the best option is to have a security descriptor for each
process as used in VMS (and advocated in a message I received a short time ago
but accidentally deleted so I can't quote it). However I don't have the
knowledge required to code this and I am too busy to learn at the moment. If
someone has some suggestions for filing system security then I would be very
interested as my main Linux programming project is the design of a new filing
system... But if the number of processes limiting code is to be developed by
me then it'll be a few dozen lines of code based on catting a few values to
file(s) in /etc/proc (but don't let me discourage you from implementing it your
way if you've got the time and desire).


Russell Coker


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