Revocation myth persists in ACM Queue article

Quoting from the "Capabilities and Naming Rights" section of:

http://portal.acm.org/citation.cfm?id=1016998.1017001&coll=ACM&dl=ACM&idx=1016998&part=periodical&WantType=periodical&title=Queue&CFID=26935421&CFTOKEN=97178047

"The “capabilities” approach performs an access check upon first access, 
and then provides a reference to an object based on that check, which 
may be used indefinitely in the future. A widely used example of the 
capability model is the Unix file descriptor. This permits the continued 
use of a file-system object following an initial lookup and access 
check. The model emphasizes performance and simpler application error 
handling—at the cost of revocation—and relies on the safety of local and 
global naming schemes."

The irony is that this paper is about virtualizing the filesystem to 
achieve better access control. I guess the myth is so ingrained that the 
author never even considered virtualizing the file descriptor, even 
though he was writing a paper about virtualization.

Tyler

--

-- 
The web-calculus is the union of REST and capability-based security.
http://www.waterken.com/dev/Web/

Re: Revocation myth persists in ACM Queue article

Tyler Close wrote:
> Quoting from the "Capabilities and Naming Rights" section of:
> 
>
http://portal.acm.org/citation.cfm?id=1016998.1017001&coll=ACM&dl=ACM&idx=1016998&part=periodical&WantType=periodical&title=Queue&CFID=26935421&CFTOKEN=97178047 

On-line without needing an ACM account at
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=170

--

-- 
David Hopwood <david.nospam.hopwood@...>

Re: Revocation myth persists in ACM Queue article

On the other hand, if you look at the author blurb at the end of the
paper, it's no surprise that he's an uninformed party...

shap

On Wed, 2004-09-08 at 17:00, David Hopwood wrote:
> Tyler Close wrote:
> > Quoting from the "Capabilities and Naming Rights" section of:
> > 
> > http://portal.acm.org/citation.cfm?id=1016998.1017001&coll=ACM&dl=ACM&idx=1016998∂=periodical&WantType=periodical&title=Queue&CFID=26935421&CFTOKEN=97178047
> 
> On-line without needing an ACM account at
> http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=170

Re: automatic policy embodiment and enforcement

The paper at 
<http://www.agorics.com/Library/KeyKos/keysafe/Keysafe.html> provides a 
fairly detailed design of a system that was meant to address the main 
points of the Orange Book and its concepts of security labels that were 
attached to data.
Such software was not built for lack of specific contracts.

Some from the military community were convinced that designs along 
these lines would meet their needs both in the letter and spirit of the 
Orange Book.

One of the key points is that just as a secure system need not attach a 
label to each value transferred between registers, neither does it need 
to attach a label to each message transferred between protection 
domains is a capability system. In each case the perimeters relevant to 
labels are coarser than the individual data transfers.

While the Orange Book was probably written assuming that all of the 
security enforcing logic would be in some kernel, to its credit it did 
not actually say so. The NCSC team that examined Keykos was pleased 
that the security policies they were concerned with would be 
implemented in a flexible environment. They did not think that the 
Orange Book was the last word in the required security policies. They 
recognized that the Orange Book was silent on the issue of viruses, 
presumably because it was seen as too much to require.
They recognized that the virus resistance provided by Keykos would 
provide a significant advantage over systems that merely met the Orange 
Book requirements.

On Aug 10, 2004, at 6:22 PM, Toby Murray wrote:

Re: automatic policy embodiment and enforcement

There are several aspects of the exchange below that puzzle me.  Perhaps 
there's some context that I'm
missing that somebody might be able to fill in for me.

Perhaps I can start with Toby Murray's statement, "...we'll have to be able 
to build these abstractions and
generate propagation rules automatically that can be enforced by trusted 
code, if capability systems are to
become practical."  I believe there have been numerous capability systems 
already in the past that have
proven 'practical' (as I understand the meaning of that term in this 
context - at least to include security/
integrity substantially greater than comparable non-capability 
systems).  They've done this without a need
for an "automatic mapping of an abstract policy specification".  They've 
done it simply by providing a
better approximation of the principle of least access - as discussed 
numerous times on this list.  One
application at a time.

Of course transitioning from the current environment of Unix and Windows 
dominated systems to some
sort of capability based operating systems is a huge practical problem, but 
I don't believe that problem
is significantly related to a need for the ability to build trusted 
abstractions and to enforce security policy
via policy abstractions by automatically propagated rules generated from 
them.  My feeling is that
such abstractions would likely be too high level to provide much benefit on 
practical security/integrity.

Re: automatic policy embodiment and enforcement

Jed Donnelley wrote:

> There are several aspects of the exchange below that puzzle me.  
> Perhaps there's some context that I'm
> missing that somebody might be able to fill in for me.
>
> Perhaps I can start with Toby Murray's statement, "...we'll have to be 
> able to build these abstractions and
> generate propagation rules automatically that can be enforced by 
> trusted code, if capability systems are to
> become practical."  I believe there have been numerous capability 
> systems already in the past that have
> proven 'practical' (as I understand the meaning of that term in this 
> context - at least to include security/
> integrity substantially greater than comparable non-capability 
> systems).  They've done this without a need
> for an "automatic mapping of an abstract policy specification".  
> They've done it simply by providing a
> better approximation of the principle of least access - as discussed 
> numerous times on this list.  One
> application at a time.

"Pracitcal" was a poor choice of word, since it is incredibly subjective.
At the most basic level, what I made the statement, I was really talking 
about being able to take some abstract policy and being able to come up 
with (say, for an object-capability sytem) a specification that includes 
a number of object type definitions and some instatiation of those types 
(which are really just a number of abstrctions on the base system). If 
these objects are trusted to enforce policy, then the definition of 
these types and the initial instation implicitly defines what can and 

RE: automatic policy embodiment and enforcement

This problem is one we ran into with e-speak.  Like other capability systems, e-speak could enforced a
security policy by properly configuring the capabilities.  The problem was that these configurations
were at a very low level. Our customers wanted to specify access policies at a much higher level. 
Management wants to say "Enforce the *-property on these subjects and objects".  A capability system says
"this configuration of objects enforces the *-property".  I think Toby is looking for the mapping between
these two.  

We didn't get that far with e-speak, and I don't know of any such tool.  The closest we came was in the Client
Utility prototype, where each object was assigned a security label.  The actual policy was specified in
terms of these labels without regard to the individual objects.

An important reason for having such a tool is assurance.  It's hard to know if you're violating a high level
policy when manipulating low level permissions.  An automated tool can avoid such problems, or at least
report them when they occur.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp

_______________________________________________

Re: automatic policy embodiment and enforcement

On Sep 20, 2004, at 6:18 PM, Karp, Alan wrote:

> This problem is one we ran into with e-speak.  Like other capability 
> systems, e-speak could enforced a security policy by properly 
> configuring the capabilities.  The problem was that these 
> configurations were at a very low level. Our customers wanted to 
> specify access policies at a much higher level.  Management wants to 
> say "Enforce the *-property on these subjects and objects".  A 
> capability system says "this configuration of objects enforces the 
> *-property".  I think Toby is looking for the mapping between these 
> two.
>
> We didn't get that far with e-speak, and I don't know of any such 
> tool.  The closest we came was in the Client Utility prototype, where 
> each object was assigned a security label.  The actual policy was 
> specified in terms of these labels without regard to the individual 
> objects.
>
> An important reason for having such a tool is assurance.  It's hard to 
> know if you're violating a high level policy when manipulating low 
> level permissions.  An automated tool can avoid such problems, or at 
> least report them when they occur.

I think this is an important difference between capabilities and acl's: 
capabilities use "lowest level" permissions that can be enforced merely 
by the VM of a capability-secure language, but they have the burden of 
proving that they are conform to higher level policies. Acl's use the 
"high level" rights from the security policy, but they have the 
(impossible?) burden of enforcing them at runtime.

Re: automatic policy embodiment and enforcement

In the course of an office move and a cold, I seem to have missed Toby's
original posting, but fortunately Norm doesn't edit his inclusions 

Toby:

I think that perhaps you have fallen prey to a ``levels of abstraction''
error. You seem to be looking at a protection mechanism -- capabilities
-- and asking what policies it implements/prohibits. Capabilities are a
policy-neutral mechanism. Like every other protection mechanism I can
think of, it is possible to misconfigure a system in such a way that
policy enforcement becomes broken.

While there are other protection mechanisms (most notably RBAC-derived
and DTE-derived mechanisms) that can enforce selected security policies,
capabilities appear (to date) to be the *simplest* such mechanism.
Speaking subjectively, I also find that they are the easiest to reason
about, but this may result from the fact that I am most familiar with
capabilities rather than from any intrinsic advantages they may have.

If I recall the thread of discussion correctly, you have raised two
issues:

  1. How do we ensure enforcement of some particular policy X
     given that arbitrary policies can be constructed, and that
     these other policies may be running on the same machine.

  2. How do we reason (you asked: how do we reason formally) about
     which capability transfers are "legal" when we wish to enforce
     some particular policy.

Re: automatic policy embodiment and enforcement

On Mon, 2004-09-20 at 14:43, Fred Spiessens wrote:
> ...Acl's use the 
> "high level" rights from the security policy, but they have the 
> (impossible?) burden of enforcing them at runtime.

Offhand, I cannot identify a single access right that is enforceable in
an ACL system that is not equally enforceable in a capability system. As
a practical matter, all of the real ACL systems I know about enforce
low-level access rights such as 'read', 'write', 'execute.'

Can you perhaps give a concrete counter-example?

I can see a (weak) argument that the introduction of "groups" into an
ACL system adds a level of policy-exploitable indirection. However, this
is not a pure ACL system in the classical sense.

I have no objection to discussing the merits and power of a "modified
ACL system", but it is very striking that every time someone wants to
argue about how an ACL system does something (anything) right, the first
step is always to augment the ACL model in some non-trivial way. This is
especially striking because the same type of augmentation so rarely is
necessary in capability-based designs. Mark Miller and I have been
struggling for a couple of years to articulate why this might be so.

> To prove higher level policies for capabilities I see two strategies:
> 1. Go down to the code level, tag variables or objects, and then run a 
> static analyzer (somewhat similar to dataflow analysis)

Yes, though control flow reasoning is sometimes sufficient, and
typestate reasoning is *often* sufficient. This is good, because if you