lkml.org 
[lkml]   [1996]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Priviledge Groups
Date

> 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")


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