[cap-talk] Capabilities - the rub, an account

Stiegler, Marc D marc.d.stiegler at hp.com
Tue Nov 21 14:23:44 CST 2006

> >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
barely interesting. 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
pyschological/training/brainwashing impediment.

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 (indeed, I just posted a new
version of E in a Walnut, modified by markm to be up to date with the
latest E release, and I did not inspect it. Had I been able to build an
automatic proxy easily, it would have made more sense to do so, since I
added no intellectual value to the process. However, all readers of
Walnut will continue, correctly, to hold me accountable, no one else). 

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

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. 

> Regarding indirect (e.g. proxy) access:
> >Those who have direct
> >access can proxy, thereby spreading access beyond your 
> control but not 
> >spreading accountability beyond your control.  The beginning 
> of sanity 
> >is for everyone, both people on this list and computer 
> security pros in 
> >general, to understand this.
> I agree to an extent (my position on this 'inalienable right' 
> to delegate should be well known on this list), but again I 
> think it understates the case against object/capability systems.
> 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?

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
also always-on.

As Sandro points out, in the malicious case, the attacker simply puts
his proxy in the startup profile of the user. 

> Another factor I believe is that such proxying doesn't seem 
> to be a practical problem from the security viewpoint. 
> Others can correct me, but I don't know of any instances of 
> script kitties or the like installing proxy access.  I think 
> part of the reason they don't is that such access isn't 
> permanent enough to suit their needs (see above about the 
> limited lifetime of processes).
> >Accountability is what you really wanted anyway. So the 2 
> requirements 
> >deserve to be rewritten to reflect what people actually want and 
> >actually can get (which happen to be the same) rather than what they 
> >think they have and think they can get (which are similar though 
> >different). A first necessary step toward security is 
> discarding one's 
> >illusions, for the attackers will discard your illusions 
> whether you do 
> >or not.
> We agree that proxying without explicit delegation is 
> possible whenever there is a communication channel available. 
>  We agree that this is important for everybody to understand 
> going forward.  I also believe that trying to block 
> delegation (at least revocable delegation - more on 
> revocation and membranes below) when communication is 
> available is pointless - though others even on this list have 
> disagreed.
> 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 peopl
> 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.


More information about the cap-talk mailing list