[Cryptography] Do capabilities work? Do ACLs work?

Bill Frantz frantz at pwpconsult.com
Tue Feb 17 00:35:36 EST 2015


On 2/16/15 at 4:56 AM, leichter at lrw.com (Jerry Leichter) wrote:

>On Feb 15, 2015, at 10:50 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>>> 2.  Policies are defined by extension at the time of attempted access....
>>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.
>No, not at all.  I'm explicitly saying that you need to record 
>the predicate as some kind of executable code; you can't just 
>record the set of actors who match it at some fixed point in 
>time.  All I'm forbidding is that you can't just assume away 
>the problem by positing that a test for the predicate is 
>already there.

OK. I haven't assumed that the test is already there. I have 
assumed there is a place to stand to ask the question, ways to 
get the data needed for the answer, and a security system coded 
to correctly respond to the answer. We both agree that to 
implement this security policy, someone is going to have to 
write isInA51().


>>> 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.
>That's fine, but you're really no longer talking about anything 
>I would recognize as a capability.  In fact, you've pretty much 
>lost your organizing model!
>
>- For ACL's, the form of open()'s code is:  For each ACL on the 
>file, check (using fixed code) whether this actor "matches" the 
>ACL and grant/deny access on that basis.
>- For capabilities, for each capability on this actor, check 
>(using fixed code) that whether this capability "refers to" 
>this file and grant/deny access on that basis.
>
>Here, you're delegating the test to an accessPermitted() 
>function.  But *we're inside of the systems's accessPermitted() 
>function*, and the whole point of choosing either ACL's or 
>capabilities was to provide a simple structure for such a 
>function that we could reason about.  If you defer to an 
>external function, you have to start your design all over 
>again.  I'll say more about this below.

No. We're not inside the accessPermitted() function -- which for 
your Area 51 example could the the isInA51() function. I am 
describing how its result gets turned into an access 
permitted/denied decision.


>>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.
>All three are important, for different reasons.  The two you 
>mention are obvious, but if I'm attempting to audit my 
>*policy*, as opposed to a particular stream of events that 
>happened to occur, this is important information.  (There's a 
>similar and fundamental idea in databases, where there are 
>predicates that are constraints and must always be true in all 
>possible states of the database, and predicates that just 
>happen to be true right now.  One of the things the relational 
>theorists clarified was the importance of this distinction.)

In the implementation I sketched, to perform audit, we would 
have to scan all the emulated inodes to discover what reference 
they had in their accessPermitted() slot. The number of 
references would probably be small, about one/policy, so the 
scan should not be too difficult. To get an idea of historical 
data we would either scan regularly, or log when we change policies.

>
>>> 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.
>I don't see that you've "implemented it in a capabilities 
>system".  You've essentially punted it to code that's up to 
>someone else to write.

Well, I think when we are implementing "exotic" policies, like 
your Area 51 policy is meant to be, someone will have to write 
some code to implement the predicate. The important thing is 
that code can be installed as the need arises, without major 
trauma to the rest of the system. That is the kind of system I 
have described.


>BTW, I'll grant you that it's a bit of a stretch for the ACL 
>system as well - but much less of one.  An ACL system always 
>has to ask:  Does this actor "match" this access control 
>entry?  For the Area 51 problem, the user has to provide a way 
>to  answer the question "Is this actor working in Area 51 right 
>now"?  The function is independent of the file, and of any 
>other ACE's on that file; all decisions about actual access 
>remain within the ACL implementation.  That's very different 
>from being asked to implement a "accessPermitted()" function.

Implementing the accessPermitted() function is exactly what you 
are describing the user to provide. We are really on the same 
page here.

Note that when I described how to implement this policy in a 
capability system, I was lazy and started with a capability 
system that had already implemented an ACL system. Note also 
that my goal was to demonstrate that capability systems can 
implement ACL systems.


>>> Interpretation 3 just ups the ante on how often you need to evaluate the set of workers in Area
>51.
>>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.
>You're now talking specific operations in KeyKOS, and nothing 
>at all having to do with the capability model as such.

Well, none of the patterns are specific to KeyKOS, they can all 
be implemented in object systems, capability based or not. I 
chose KeyKOS because:

  (1) I'm familiar with it. :-)
  (2) It had a running implementation which was good enough to benchmark.
  (3) That implementation was documented in a paper I could reference.


>
>Stepping back for a moment:  I've implemented access policy 
>mechanism (within particular programs) in the past, and I've 
>always found that if you've already got an object-oriented 
>model, capabilities are the most natural way to go *for the 
>implementation*.  How you want to *represent policies to the 
>user of the system* is a whole other story.  In practice, 
>something like ACL's is usually a better fit.  Policies are 
>phrased in terms of sets of users (often defined by predicates 
>that vary over time - i.e., by comprehension).  But the 
>user-interface "ACL-like" things usually are not directly 
>representable *as* ACL's; one way or another, you have to 
>translate them into whatever your system actually uses 
>internally.  And, *much* harder (I have yet to see a plausible 
>solution) you have to translate the *net effect* of all the 
>rules in the system into something comprehensible to users.

Indeed, the range of desirable security policies is not well 
studied. Mostly people limit themselves to the ones they think 
can be implemented. Your Area 51 policy is a refreshing change. 
And reflecting them to the policy definers is a serious problem. 
We all want a computer which does what we mean and not just what 
we tell it to do. :-)


>None of the operating systems in wide use hew to 
>object-oriented principles.  There are bits and pieces that 
>look object-like, but that's as far as it goes.  Since people 
>have been arguing for - and building examples of - 
>object-oriented OS's for several decades now, with little 
>effect on what's actually being used, at some point you have to 
>concede that maybe there really *is* something missing from the 
>object-oriented framework when it comes to OS's.  (I've come to 
>that conclusion more generally, but that would take us too far 
>astray.  OO is something that can be appropriate, but it can 
>also be inappropriate.  The trick is knowing how to judge that, 
>and having alternatives design styles to use when it's inappropriate.)

I'm not convinced there are important things in implementing 
security policy which are missing. There certainly is missing 
mind-share, and the ability to use a system is much more 
important for its sale than what kind of security policies it 
can implement.

We have a number of legacy systems which would be very expensive 
to replace, which seems a complete explanation for where we are. 
Heck, we can't even get the old systems to run programs with 
less that all their user's privileges, although there have been 
several demonstrations of how to do that without major system 
changes. Only newer systems like iOS move in that direction. 
 From these facts, I would conclude that we will only get 
security improvements in completely new application areas -- 
hardware + software. Somehow, I don't think we will see an 
improvement with the Internet of Things though. :-(


>It's also the case that we've spent so many years on the debate 
>of ACL's OR capabilities that we've closed our eyes to the 
>limitations of *both* - and, indeed, of the underlying access 
>matrix model.  Relational database systems, and the security 
>policies appropriate to them, don't fit either; and, indeed, 
>the usual way to define access policies in RDBM's (beyond 
>simple ones that are usually done in a style that's mainly 
>ACL-like) is to define a query that gets combined with a user's 
>query, filtering out the results that are not supposed to be 
>accessible.  (I guess, looking back, that that style of doing 
>things led me to the Area 51 problem.)

I really have no idea of the issues in database security.

-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506      | contact sport.               | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032



More information about the cryptography mailing list