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 casey@sgi.com fax: (650) 933-0170
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/