Messages in this thread |  | | From | bofh@snoopy ... | Date | Thu, 26 Dec 96 22:16:53 +1000 | Subject | Re: 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
|  |