[cap-talk] Fundamental issues for capabilities (was: Unix breaking TCSEC)

Jed Donnelley jed at nersc.gov
Tue Nov 7 16:54:25 CST 2006

At 09:55 PM 11/1/2006, Mark Miller wrote:
>On 11/1/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
> > cap-talk,
> >
> > Related to my previous note on capabilities and NCSC TCSEC, it
> > occurred to me to consider some features of systems like Unix and
> > Windows in the light of those criteria.  In particular the feature in
> > Unix that plash uses where open file descriptors can be communicated
> > through pipes (please correct my terminology or concept if I've
> > missed it here) seems to me to completely break all the TCSECriteria
> > that are discussed in the document that I posted just as "traditional
> > capabilities" do.  Namely, such communication can allow file access
> > despite not being allowed by the nominal Unix rwx ugo access
> > controls, and there is no auditing on such communication.
> >
> > I wonder if those folks (TCSEC evaluators) feel that such a "feature"
> > in Unix breaks it's opportunity for providing security?
>I talked to the architect of Sun's "Trusted Solaris" operating system,
>who explained to me that Trusted Solaris disallows such "Unix Domain
>Sockets" between compartments (their "zones") precisely because they
>believed that the ability to pass file descriptors was too dangerous.

and yet seemingly they allow communication between compartments
(if not then of course there would be no need to block communication of
open file descriptors) which of course allows proxy access - less efficient but
the same access.

I believe:

1.  the failure to come to grips with communicating conspirators
(which in many ways ties into the distinction between "discretionary"
and "mandatory" access controls that I consider meaningless) and

2.  the lack of appreciation for the fact that access delegation is
vital to developing secure and reliable computer systems.

[Aside: Blocking delegation (or trying to have it all micro managed by system
administrators or managers) makes systems less secure rather than
more secure.  The most secure and reliable systems are those that
can delegate exactly the access that is needed through a simple modular
means (objects).  Nearly all the delegations that take place are done in
"good faith" by programs acting as intended.  What's important in
developing secure and reliable computer systems is to allow the
software acting in good faith to minimize the authority given to any
piece of software so that when some piece of software fails to act
in good faith (maliciously or unintentionally) that it does as little damage
as possible to security and integrity.]


3.  generally the belief that people and programs can't and shouldn't 
be trusted
to delegate access that they are (and presumably need to be) given.

are at the root of the rejection of the capability paradigm by people 
like those
who developed the TCSEC.

What puzzles me some is that they seem to be willing to accept as a
consequence the granting of ambient authority (the authority of a person)
to programs acting on their behalf as a consequence.  They speak in high
sounding terms of "subjects" and include processes as subjects and suggest
that access control can be managed on a per process basis, but:

a.  There are no commercial systems today (correct me if I'm wrong in this)
that have mechanisms that are used to routinely manage access on a per
process basis.  The only means available is the pseudo user mechanism that
is so awkward and impractical that in practice it's never really used (except
perhaps in efforts like plash and Polaris to introduce "capability" delegation
into commercial systems).  Imagining that system administrators or managers
would control access on a per process basis is absurd.


b.  If delegation is to be done on a per process basis then of course
any such delegation must be "discretionary".

These are the issues that I believe we in the capability community need to
come to grips with, clarify, and communicate to the IT community/industry if we
are ever to get any traction with the capability paradigm.

Beyond the above I believe we have some internal issues to deal 
with.  I think the
most important (but also likely the least tractable) is coming to 
some sort of agreement
on just what symantics an object "capability" needs to have.  I 
believe the internal
arguments about this feature or that feature of implementations fragment the
capability community and weaken the message.

However, perhaps a more hopeful area of improvement in the capability message
would be to standardize, simplify and make more efficient the revocation and
membrane mechanisms.  To take an extreme position for comparison, if every
communicated capability acted as a membrane and was revocable (and audited),
I think the concerns of a community like that represented by TCSEC would
be blunted.  In what I consider a "traditional" "descriptor" 
capability implementation
(e.g. Dennis and Van Horn's "Supervisor", RATS, I think KeyKOS, EROS, etc. -
I quote traditional and descriptor to distinguish them from those 
terms used in the
P-1935 paper which seem odd to me) I believe it would be fairly easy to support
revocation (even through membranes) and auditing for all capability 
If we could make this be the standard/norm for capability systems I believe the
security community (e.g. US defense agencies, etc.) would be much 
more interested
in the capability paradigm as a tool to improve the 
security/integrity of computer

--Jed http://www.webstart.com/jed/ 

More information about the cap-talk mailing list