Re: Priviledge Groups
Keith Rohrer (kwrohrer@uiuc.edu)
Wed, 18 Dec 1996 01:18:48 -0600 (CST)
> A scheme like this, if done right, could eliminate the vast majority of
> security holes that show up in unix... While we're at it, it would be a
> good idea to have restrictions also, such as not allowed to fork, not
> allowed to exec, not allowed to open files for writing (possibly even
> with a list of files excepted from the restriction). This could be used
> to prevent priviledged programs from expanding their access. The program
> should also be allowed to add restrictions to itself or drop privledges.
If this isn't handled in a constant space:process ratio I can see a
wonderful little denial attack where the nuisance process constructs
privs and requests that it be denied them (foreach i (`find / -name \*`)
deny-me read $i; deny-me write $i; deny-me execute $i; deny-me chown $i;
deny-me floss $i .....). Actually, while a shared library call would
be unsuitable (and linking it statically would make you recompile every
time a hole in the library is found), the kernel could stick the denial
list in pages the program couldn't access but would be part of it for
accounting/paging/whatnot purposes...
Keith (remembering INTERCAL: "please abstain from abstaining")