[cap-talk] Capabilities vs. identity/acl - the rub, rub, rub
Jed at Webstart
donnelley1 at webstart.com
Tue Nov 21 20:37:19 CST 2006
At 12:23 PM 11/21/2006, Stiegler, Marc D wrote:
> > >1. It makes no difference whether you are using caps or acls, you
> > >cannot tell who has access, you can only tell who was given a direct
> > >enough access such that you can hold them accountable.
> > While this is of course literally true, I believe it
> > understates the case against object/capability systems. In
> > identity based ACL systems access is only directly granted
> > through the identity based ACL mechanisms (e.g. Unix).
> > Since programs run as users with their identity (I of course
> > know this non POLA is a problem, please don't jump on me here
> > as I play devil's advocate) there is no issue with separate
> > "principal" identities for running
> > programs (processes, active objects). Consequently one can determine
> > who has direct access by looking at the ACL (e.g. ugo rwx and
> > group in Unix).
>I continue to be puzzled that you of all people should consider the
>tracking of direct access to be important, useful, relevant, or even
Ha. That sounds like a good issue to get to the bottom of. Perhaps
we'll get to discuss it Dec. 1.
>There is a psychological problem that IT people with
>believing that direct access is somehow important, and a psychological
>problem that IT people have does indeed present a barrier to adoption,
>but you seem to be acting as if it were more than a
I believe it is. We continue.
>As it happens, lately when I've been giving presentations on secure
>cooperation, I've been asking my audiences whether they ever set an acl
>to share a file, or whether they always simply send email when they want
>to share a file. The answer is stark: few folks in the real world even
>tries to use acls (just as well, since they would quickly find, as I
>noted earlier, that they don't work, i.e., if you have read authority,
>delegation of that authority is impossible except via email and
>proxying). People with real work to do send email, and manually update
>files, only sometimes with inspection.
Hmmm. Perhaps this difference in views is influenced by the difference
in our day to day lives. I am a Unix system administrator (by day ;-).
I deal with ACLs all the time (as Unix ugo rwx). Of course you can
write off my case. However, as part of my admin role I support an
LDAP infrastructure for our computer center. We have a global file
system that uses the Unix access mechanisms including a huge
set of groups that track projects, organizations, etc., etc. These
mechanisms are widely used by our users (3k of them) for access
control. Sure, they copy files by email as well. They also copy
paper documents and hand them around. Those action are outside
the scope of the access control model. No problem.
For network access I agree that there is little option but to communicate
data by copying it (e.g. sending a file by email). However, even on
the network identity and identity based access control I believe
is ascendent. If I go to my bank or yahoo or ... you name it.
I identify myself and them am given access permissions.
Generally have no means for delegation, but the few means
that there are (e.g. PayPal) are identity based. Even when I
go off to get my email - an identity and authentication.
>Anyone who thinks the log of direct accesses has the slightest thing to
>do with who actually works with the file is living, not on Earth, but
>inside some researcher's theoretical model of computing that has been
>simplified to the point of uselessness to afford mathematical
Sorry, I don't agree (good discussion though). I think perhaps we
are mixing levels. At the level of access within a system based
on identity, the identity and acls do matter. It may well be that
there are services that are proxying (e.g. a Web server comes
to mind) access or copying out data (e.g. your email example), but
I don't believe those examples break that base identity/acl based
paradigm, they 'just' extend it.
>And this is the good news. If IT departments were able to enforce the
>rules represented by acls, all of western civilization would collapse
>under the weight of the inability to cooperate any more.
Hmmm. Do you mean we couldn't network. I really think we mostly
agree on at least the technical aspects of what is going - because
those are so obvious. I certainly agree that sharing across administrative
boundaries and across the network is important. I can even agree
that it dwarfs ACL based sharing in terms of practical use. However,
I don't see any way to use those facts to provide leverage for a capability
model - either at a system level or at a network level.
Perhaps I should get out of my devil's advocate role here for a moment.
What I want to see is object/capability systems doing the 'right'
POLA thing at system and network levels. Can you suggest
a path to get there? Throw the current bums out and put some
new object/capability bums in their place?
> > The most important factor in this area I think is that any
> > proxying disappears when the active process doing the
> > proxying goes away - as it inevitably does in many cases
> > (often at a logout, a kill, but certainly when a system
> > restarts in today's systems).
>So the plan is to secure our systems by ensuring they are unreliable
>enough so that they have to be rebooted periodically? Should a law be
>passed to ensure that the always-on pervasive computing world is
>illegal, to ensure that the proxies get shut down from time to time?
and of course proxies can be auto restarted. I believe the root of the
issue is that if you want to nail down where an access is coming
from on an identity/acl based system, you can:
1. Look at the object, it's permissions for owner, group, world.
2. You can look up the groups and come up with a set of identities
that can access the object.
3. You can look for any process with any of those identities.
Any access must come from one of those processes.
In principle you can turn on auditing (e.g. a richer syslog)
that will show which processes with which identities
accessed which objects. Tell me it's a dream...
I really think you're underplaying the strength of this paradigm.
Just because there can be proxy accesses doesn't mean that
the paradigm is invalidated. It just means that you can only
trace the access as far as the proxy. At least you can get
that far. How far can you get with the above approach in a
capability system? (listen to me, the real devil...).
>Actually, this discussion slid off to the side somewhere. I was
>addressing the situation where the people involved were intentional
>collaborators. If the folks are intentional collaborators (which, by the
>way, is the way real people in real organizations get things done, i.e.,
>the enormous majority of intentional collaborators are supposed to be
>collaborating, and would not be doing their jobs if they failed to do
>so, regardless of the impediments we throw at them), then the proxies
>will be at least as reliable as the logons, i.e., even if you shut the
>computer off, the proxy will come back on. Indeed, the proxies of the
>future will probably be built on separate servers that specialize in
>always-on reliability, at least until all the laptops and handhelds are
Fine. I'm all for moving in that direction for networked access.
>As Sandro points out, in the malicious case, the attacker simply puts
>his proxy in the startup profile of the user.
Even in the non malicious case I guess.
From my perspective, however, this only shows the difficulty in
extending the identity/acl based access control model to a
network. Still, that doesn't stop people from doing it.
Seen any .htaccess files lately? How do you do access control
on the Web? Answer - by identity and acls. Sure, perhaps
much/most of the sharing is open (no access control) and done
by copying (e.g. the emailing of files), but what little access
control is done is still done by identity and acls. Do we disagree
> > <snip>
> > Even if we accept the above as truths to deal with, however,
> > all object/capability systems that I'm aware of do much more
> > direct delegation without the sorts of controls that the
> > security people
> > want to see. This is partly because they just do much more
> > delegation.
> > More delegation is to the good (I believe), but if one
> > follows Lampson's argument it comes at the cost of additional
> > complexity (certainly true to some extent as there is more
> > delegation) that is unmanageable in a practical system.
>Yeah, another one of the related tricky things (or entertaining things,
>depending on perspective) is that the concept of "unmanageable" and
>"complex" are dependent on whether you do authorization analysis or
>permissions analysis. As pointed out earlier, since real people use
>email, the system is already, from an IT perspective, too complex and
>unmanageable. It would be best to feed their illusions, from a marketing
>perspective: the IT analysis comically assumes that email does not
>exist, and living inside this fairy tale they get to have tight control.
>Very festive. Our grandchildren will laugh at the silliness of it all,
>if they can be brought to believe it really was this way. I am keeping
>snapshots of the great dialog boxes of the ages (such as, "Create a new
>password. Please pick a password that is easy to remember but difficult
>to guess") for the day when they want to do a Saturday Night Live skit
>on how ridiculous security used to be.
Sigh. I wish I could see what will replace the silliness that you refer
to and, more importantly, how the replacing will happen. You realize
of course that this has been going on at least 40 years that I know
of. Even if you start from the Internet explosion, I've still seen no
movement in any other direction. You're email example has almost
always been around in the form of copied (even if hand copied)
documents. We had Xerox machines even prior to 1966
(I saw my first at HP in that year) and of course there were
other means for copying prior to that. That didn't stop the
identity/acl control model from building and remaining ascendent
as it has.
Have you ever actually received a capability in an email?
By "actually" I mean a permission to access something that
wasn't assumed to be accessible by the whole world?
Not a copy (e.g. the file in an email example), not a URL
open to the world, but shared and limited access or an object?
The only example I can think of are the wideword capabilities
that I created and received back through https (and likely by
email, but OK). That's certainly a trivial set from the viewpoint
of general access control. I don't believe your example of
sending attachments via email represents a changing of
the tides. It is as you say outside the access control model.
It doesn't even use anything like a capability - though I'll bet
there's an identity and a password/cert somewhere in the path
(e.g. when you access your POP or imap or Web server
to get your email).
More information about the cap-talk