[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