[lkml]   [1999]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: caps in elf, next itteration (the hack get's bigger)
Andrej Presern wrote:
> On Sat, 17 Apr 1999, Casey Schaufler wrote:
> >The choice of capability granularity is a sigificant issue. On
> >Irix there are about 40. On DG/UX there are 330. Me, I prefer a
> >set that I can deal with.
> Oh, I see. So why is this issue of capability granularity so important?

I can, after a beer or two, make an argument for a system with
a single capability instead of a special uid (i.e. root) being
the more secure. I can argue that a system with a seperate
capability for each access check in either the kernel or in
a trusted application is best. The important thing about the
granularity of capabilities is that it allow privilege (note
the use of the P word) to be allocated to a degree which is
consistant with the system's security model. One reason why Unix
based systems have struggled against the B2 criteria is that
the Unix security model includes a binding between user ID, which
is a DAC concept, and the capability to override policy. Once the
user ID and capability to override policy are decoupled it
becomes necessary to decide how to map the new capability policy
to the implementation. There are several factors which infleuence
the mapping, including level of assurance desired, how close the
code is to being done, how complex the security model is, and
what capability list representation has been chosen. I personally
think that the largest single factor is backword compatability.
Large numbers of capabilities, especially those designated for
applications, require more work in applications than fewer.

Hence the brewhaha. The classic arguement goes like this:

"The model says ...."
"But the code says ...."
"Fix the code!"
"Fix the model!"

Repeat as necessary.


Casey Schaufler voice: (650) 933-1634 fax: (650) 933-0170

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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