[cap-talk] Capabilities vs. Classifications

Jed at Webstart donnelley1 at webstart.com
Wed Dec 21 14:41:46 EST 2005


At 08:51 AM 12/21/2005, Anthony Hannan wrote:
>Hello All,
>
>I have long been a fan of capabilities, but recently I have been 
>thinking about security classifications (aka ACLs) and am struggling 
>to decide which is better. By classifications, I mean a subject 
>classifies an object according to how sensative it is, and then only 
>subjects authorized to access that sensativity level are allowed to 
>invoke that object (ala Bell-LaPadula). This is the model used in 
>language-based information flow security [1], which guarantees that 
>sensative objects cannot be invoked by unauthorized subjects. Note 
>that the classifications model does not also imply the mistake of 
>granting each process the authority of the executing user (confused 
>deputy). Instead, each program (function, object) is also a subject 
>that is authorized at a certain security level(s). Also, the 
>authority to invoke objects classified at a certain security level 
>is separate from the authority to downgrade or classify objects at 
>that level. Finally, not every object needs an explicit 
>classification, these "neutral" objects are given the most sensative 
>classification of its inputs. For example, if the invocation of 
>foo(x,y) yield neutral object z, then z is given the "join" of the 
>classifications of foo, x, and y.
>
>I see the following trade-offs between capabilites and classifications:
>With classifications you do not have to trust the subjects 
>(functions) you give your objects to. You can give your classified 
>objects out without worrying, knowing that only authorized subjects 
>will be able to invoke them (assuming you trust the kernel/middleware).
>However, classifications requires extra maintainance: you have to 
>classify objects, and you have to authorize subjects. I could 
>imagine using the capability model to hand out authority, ie. you 
>give the authority to subjects you trust. But this "meta" capability 
>exchange would be at a much smaller and controlled scale.
>
>So, I see capabilites vs. classifications as a trade off and 
>therefore hard to decide which is better. I am very interested in 
>your opinions.

As you may know there has been considerable discussion of this topic 
on this list, much recently, and more over the years.  You might find 
it interesting to look back at some of that discussion on the list 
archive - http://eros.cs.jhu.edu/pipermail/cap-talk/ - though I have 
to admit I don't know of a good way to search that archive 
(anybody?).  My most focused treating of the topic appears in:

http://eros.cs.jhu.edu/pipermail/cap-talk/2005-December/004392.html

and in follow-up discussion.  I think you might find some useful 
references in the above.

I will mention that I spent a considerable part of my IT career (20+ 
years) at Lawrence Livermore National Laboratory, a US nuclear 
weapons laboratory, where I implemented and supported an operating 
system that provided classifications for data objects and clearances 
for subjects (processes and people).  That system allowed (I argue 
had to allow to avoid partitioning the system) explicit 
declassifications - a high clearance subject communicating to a low 
clearance subject, in effect "declassifying" data, but it did enforce 
forms of the so-called 'simple security' and '*' properties (e.g. see 
the above reference and perhaps
<http://www.erights.org/elib/capability/duals/boebert.html>http://www.erights.org/elib/capability/duals/boebert.html 
)

In organizations that deal with military classification of data, 
there is often a separation between what are referred to as 
"Mandatory Access Controls" (MAC) and "discretionary" access 
controls, with the term "need to know" often being used when talking 
about the later.

I have a very strong opinion on this topic.  In my opinion, beyond 
the question of which is better between classifications and 
capabilities, I argue that the so-called MAC systems using 
classifications as you describe are counter productive.  While well 
meaning, they create so many administrative barriers without 
providing any effective protections that I believe they make 
disclosure of classified information more likely than with many 
simpler systems, including capability based systems.  A big part of 
my dislike and distrust of such MAC systems is what I consider the 
dangerous assertion and illusion that there is anything effectively 
"mandatory" about them.  That is that one can, as you say "give your 
classified objects out without worrying."  That statement simply 
cannot be true.  Specifically, if one 'gives out' classified objects 
(objects through which one can access classified data), then any 
subject receiving such access can communicate that classified data 
anywhere that the subject is able to communicate, period.

Capability systems on the other hand are based on the sound 
"Principle Of Least Authority" (also sometimes POLPrivilege) that is 
often given that "need to know" name in military circles.  In 
applying this principle, no subject trusts any other subject (by 
granting permissions through communication) with any more permissions 
(collectively authority) than is needed for proper 
functioning.  While there is a certain tension in capability systems 
in terms of how finely permissions are divided and communicated, 
generally this paradigm works quite well where it has been 
implemented.  Under the capability approach to access control there 
are no illusions.  Once a permission has been granted it can be 
exercised to the full extent, including granting to other subjects 
where communication is possible (since any subject can proxy such 
access in any case - regardless of any "mandatory" controls) - though 
there continues to be some debate, even on this list, on how and if 
such capability "delegation" can be permitted in capability 
systems.  To me it appears that the supporters of "do not delegate" 
are coming from the same misguided school that argues for the 
'Mandatory' in Mandatory Access Controls.

I see some value in labeling classified data and even in providing 
clearances to subjects, but to my thinking the value of such labeling 
is primarily to prevent inadvertent disclosure of classified data to 
uncleared subjects.  It's the notion that controls for classified 
data are in any sense "mandatory" that I consider dangerous.  From 
the perspective of any subject wishing to exercise a permission that 
it doesn't have, any form of access control is mandatory.  However, 
the adherents of mandatory access control systems (e.g. the ACL and 
role based access controls such as NSA's Security Enhanced Linux, 
SELinux) seem to be under the illusion that even if a subject has 
been trusted with access to an object (a classified object "given 
out" as you say) and is allowed to communicate with less trusted 
subjects (e.g. subjects with lower clearances) that a MAC system can 
keep the trusted subject from allowing the un trusted subject access 
to the classified object (data).  This is clearly not the case.  I 
consider any efforts to suggest that it is as dangerous and leading 
to weakened security.

More generally on the topic of capability list systems vs. access 
list systems it has been suggested that there is an equivalence 
between ACL and capability systems, with the one (capabilities) 
simply keeping the access permissions with the subjects and the other 
(ACLs) keeping the access permissions with the objects.  This widely 
touted position is wrong.  There is a good exposition of why in the 
"Capability Myths Demolished" paper at:

http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
(I disagree with the treatment of the Boebert paper in the above 
document, in case you might happen to read that)

The main point there, from my perspective, is that the absolutely 
crucial dynamics of systems (how permissions are communicated) are 
ignored when considering this false duality.  In capability systems 
subjects are able to grant portions of their permissions to other 
less trusted subjects to carry out work on their behalf - enabling a 
general system of modular trust to be established.  With ACL systems 
there seems to be the general assumption that some sort of God 
(usually in the form of a system administrator) is going to establish 
what subjects have what permissions to what objects and that's 
it.  Part of this problem comes from the fact that if one were to 
allow any subject that is granted a permission in an ACL system the 
authority to grant that permission to other subjects (add them to the 
ACL), then the system would no longer be viewed as "mandatory".  The 
question that then arises in such "mandatory" systems is, Who does 
have the authority to add elements to ACLs.  The structure for 
dynamically managing ACLs in MAC systems then becomes complex enough 
that it acts as a barrier to good modular design for subject 
interactions and ends up working against protection of data and other 
sorts of access - in my opinion.

You asked.


--Jed http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eros.cs.jhu.edu/pipermail/cap-talk/attachments/20051221/ebf28efb/attachment.html


More information about the cap-talk mailing list