Messages in this thread |  | | From | Keith Rohrer <> | Subject | Re: Priviledge Groups | Date | 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")
|  |