[Cryptography] Do capabilities work? Do ACLs work?

[Bill Frantz]

On 2/15/15 at 5:03 AM, leichter at lrw.com (Jerry Leichter) wrote:

>Consider applying the security policy:  File F can only be accessed by those working in Area 51.

I had to stop for a long time to figure out what "working in 
Area 51" could mean. First of all, unless the computer is in 
A51, we must be talking about a remote user of the computer and 
not an actor[0] running on the computer. The actor is actually 
what is doing the access, presumably for the benefit of one or 
more users. Wow, it's complex already. We could have zero to N users.

Does working in A51 mean job responsibilities include A51? How 
about connected from within A51 or GPS says is in A51? What 
happens if the user is not connected when the actor requests 
access? Fortunately, we can abstract these questions away so at 
the overall system level, it doesn't matter.

As I respond below, I am going to assume we can program an actor 
in the system that can be called passing an identity token for 
whom/what ever is doing the access and it comes back with a 
boolean isInA51(). We can hide these difficulties and others in 
this actor.


>This is an ambiguous definition of a set (perhaps) defined by comprehension rather than extension.

?? Is "comprehension" a technical term? What about "extension"? 
Please explain.


>We can look at three plausible interpretations:
>
>1.  Policies are defined by extension at the time they are 
>created:  Produce the list of all people (or other actors in 
>the system, if appropriate), construct the set of those who are 
>currently working in Area 51, and grant each of them access.

This approach seems like Role Based Access Control (RBAC). If 
they work in A51, they have the A51worker attribute in their 
role set. When we set up the system for this policy, we would 
add the role A51worker, identify which actors were in that role, 
and which objects require that role for accessing them. I don't 
know if the above approach allows for removing someone from the 
role, but classic RBAC systems do. Just remove the A51worker 
role from their role set.


>2.  Policies are defined by extension at the time of attempted 
>access:  At the moment an actor tries to gain access to an 
>object, update the policies to reflect current reality before 
>applying them.  That is, what matters is whether the actor is 
>working in Area 51 at the time they try to gain access to the object.

Ah, I think I'm beginning to see from where my disconnect from 
this approach stems. This approach is assuming a static 
implementation of the policy mechanisms, with no place to add my 
isInA51 predicate and tests for it.

One of the advantages of working with the Unix simulator in 
KeyKOS is that all the code affected by the addition of support 
for the A51 policy is user code. None of it is privileged. This 
makes such changes much easier to implement, test, and deploy.


>3.  Policies are defined by extension at the time of each 
>operation on an object.  (The difference between this and 2, in 
>more familiar terms, is that 2 controls who can open a file, 
>but once it's open they can do what they wish with it; while 3 
>would validate every read, write, etc.)
>
>Interpretation 1 could be implemented by either ACL's or 
>capabilities.  For suitably defined ACL's, it involves 
>attaching the definition of a predicate on actors to F, and 
>evaluating it against any actor who attempts access.  ...
>
>Interpretation 2 adds little or nothing new for ACL's.  It's 
>unlikely that any ACL system would implement Interpretation 1 
>by materializing a list of all the actors who are working in 
>Area 51, which is what a capability system would have to do - 
>so I cheated a bit.

Hmmm. If I were to modify the KeyKOS Unix environment[1] to 
support this class of policy, I would add a reference to an 
accessPermitted() object to each file object. The open() call in 
the Unix environment would call it to see if access should be 
granted. These accessPermitted() objects can be dynamically 
changed as new policies are created. Once this general support 
has been implemented, the Unix simulator would not have to be 
modified for new policies since it is only interested in the 
Yes/No answer, and not the details of the new policy being implemented.


>If you really wanted to implement Interpretation 1 in an ACL 
>system, you'd want to store a historical record of changes to 
>the Area 51 roster, and have ACL's that looked, not at current 
>membership, but at membership at some point in the past.  I've 
>never seen a system that does this, though databases that allow 
>such queries to be posed are widely used - and it's worth 
>noting that if you want to be able to do complete auditing and 
>forensics, you need to be able to answer questions like:  "Did 
>P have access to F at time T"?

I don't understand the issue here. While it might be interesting 
to know if P could have accessed F at time T, it seems to me 
that it is more important to know, did P access F at time T, and 
even more important, should P be granted access to F now.

Depending on requirements, and details of how the 
accessPermitted() return changes over time, these data could be 
kept. In many cases it will be relatively inexpensive, but worst 
case -- cell phone GPS polled every 5 seconds for being in A51 
-- it might be quite costly.


>Interpretation 2 is by far the most common one.  It's also not 
>at all clear how one might reasonably implement it in a 
>capabilities system.

See above.


>Interpretation 3 just ups the ante on how often you need to 
>evaluate the set of workers in Area 51.  If that's expensive 
>... it becomes much more so.  The only system I know of that 
>implements this, and only to a limited degree, is Windows:  If 
>you remove a user, his existing processes are quickly killed.  
>(If you go to lower levels of abstraction, this is common:  
>CPU's check access rights on every memory access.)

If I want to implement this interpretation -- which is better 
than Unix because it tests on every access and not just open -- 
in KeyKOS I would arrange a callback whenever the user's A51 
status changes. I could then sever that user's access to the 
file. This operation is quite cheap in KeyKOS, although testing 
for change in status might not be cheap. (See above.) I could 
also call isInA51 on each access, but this approach is likely to 
be expensive.

<for KeyKOS geeks>
There are two ways to sever access to an open file in the Unix 
simulator. One would be to post an event to the simulator 
instance and have it stop accessing the file. The other acts at 
the segment level (think Multix). If we give the simulator a 
newly created segment capability for each open -- which maps the 
underlying data -- we can destroy that capability, preventing 
further access while leaving the data in the segment accessible 
to other actors.
</for KeyKOS geeks>

I'll comment on "Capability Myths Demolished" separately.

Thanks for an interesting straw-man policy Jerry.

Cheers - Bill

[0] I am using actor according to my understanding of Karl 
Hewett's actor model of computation. Unfortunately, 
understanding Karl is a bit of an art form. :-)

[1] <http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html>

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032