[cap-talk] - Bellizzomi - Users in object/capability systems (was: MLS gone bad, Lampson)

Jed at Webstart donnelley1 at webstart.com
Tue Nov 28 15:49:55 CST 2006

At 01:11 PM 11/28/2006, Valerio Bellizzomi wrote:
>On 27/11/2006, at 14.59, Jed at Webstart wrote:
> >POLA perhaps, but for a user shell POLA must necessarily provide
> >all the access the user has so that any such access that is appropriate
> >(POLA) can be given to programs running on the user's behalf.  I believe
> >this means that the user's "shell" (perhaps others prefer the term
> >"power box") must have all the user's authority.
>Yes, but not all the time the user is logged in.
>Example: if a user leaves the workstation and the session becomes idle
>(with no programs running), and a screen saver is fired up, fewer
>authority is needed in this time.

I consider the above a nit:

1) In information technology as elsewhere, a nit (pronounced NIHT) is 
a small, usually unimportant imperfection in something. People who 
have unusually high or unreasonable standards for the quality of a 
thing are sometimes referred to as nitpickers.

> >>OTOH, the authentication of user could be executed in two phases:
> >>1. login setup phase = enter username+password,
> >
> >Of course there are many ways to do authentication - namely
> >to bind a person to a communication stream.  Username/password
> >is of course one (ssh key exchange, biometrics, etc., etc.)
> >
> >>2. login commit phase = enter "control code".
> >>The commit phase could be subject to timeout.
> >>This is inline with current model of atomic action kernel, "setup phase"
> >>and "action phase".
> >>It isn't a panacea but it is harder to steal two authentication codes.
> >
> >I'm sorry, but you lost me in the above.  Are you suggesting augmenting
> >any given authentication scheme (e.g. biometrics) with another
> >(e.g. ssh key exchange) for better tie-in on authentication?
>Basically I suggest using two passwords, but this isn't the real issue

I agree.

>I was suggesting to make the login process strictly tied to the
>kernel model of operation.

I'm afraid I still don't understand what you mean by the "kernel model of

> >><snip>
> >> >If I understand your meaning I believe that's what I'm trying to do.  We
> >> >must recognize that communicating conspirators (proxying) is always
> >> >possible.  What we want is mechanisms that recognize this truth and
> >> >provide us as much auditing/control as we can achieve given that
> >> >permissions can always be communicated (where communication
> >> >exists of course).  That's where I'm trying to go in the "Re: [cap-talk]
> >> >Capabilities - the rub, an account, base functionality" thread.
> >>
> >>Of course, if I have access to a file and you don't, I would just email it
> >>to you or print it and hand it to you.
> >
> >This is something that MarcS has mentioned a number of times.  I
> >think it's important to note that sharing a copy of the data in a
> >file is not the same as sharing access to the file.  With shared read
> >access new changes are visible to whoever has that read access.
> >With shared write access of course such permission allows
> >modifying a file into the future - long after its contents have
> >changed (e.g. new board secrets have been added).
>If you can share, you don't need to do proxying.

Proxying is a means to do sharing.  Copying data does no "sharing"
as I was describing above (shared access).  I'm not sure where we're
going with this thread.

> >I believe adopting such means to track delegations would go a
> >substantial way toward addressing some of the concerns of the
> >TCSEC folks (though not Lampson - whose concern seems to be
> >about complexity induced by POLA.  I believe he wrongly assumes
> >that POLA can't be simple and natural - like parameter passing).
> >I also believe such additional tracking needn't itself introduce
> >onerous administrative complexity (e.g. the recent Brinkmann
> >discussion).
>I agree.

Good.  I don't know if Alan K. will read this, but I think he and I
are having a comparable discussion also through the cap-talk list.

> >>Stopping communicating conspirators would require a military-like
> >>organizational model at human level, if it suffice.
> >>One thing that could be avoided inside the software to a certain extent,
> >>is the possibility of "wall-banging"..
> >
> >Hmmm.  Of course an easy way to stop communicating conspirators
> >is to stop the conspirators from communicating.  Stopping communication
> >by "wall banging" in shared resource systems is a hard problem.  My
> >approach generally is to not utilize shared resource where such wall
> >banging might be a concern.  Beyond such "covert channels" if
> >communication is only enabled in a system by possession of a capability
> >and capabilities are distributed according to POLA, then I think you're
> >doing about as well as you can.  You're doing so hugely better than
> >anything we have today that I think the delta can be left to our
>Wall-banging is one of the problems Coyotos and caps in general are trying
>to solve. If you read carefully the ASPOS/PP, it already takes some
>countermeasures to wall-banging.

At this point I personally think any such efforts are likely a waste of time
and effort.  I believe that the only way to deal with wall banging 
(which effort
is in itself likely not a good use of time) is to limit shared 
resources.  I think
the trade-offs are clear in this area.

> >Hmmm.  I think the issue Lampson (who's quite well known and generally
> >well respected I should mention) is addressing is the complexity that
> >arises out of requiring administrators to manage ACLs - whether the
> >owner of an object protected by an ACL or an administrator of a system.
> >In either case I think you run into the problem of "fatal deceit" that
> >MarcS mentioned.
>If I wanted to follow his suggestion of "Everything should be as course
>grain as possible because otherwise you won't be able to administer it."
>then I wouldn't ever use the rwx ugo stuff, but just plain DOS read-only

We may not "want" to use coarse grain access control (POLA as an abstract
goal is fine), but what Lampson is arguing is that if you try to use fine grain
access control you will induce so much bureaucracy, overhead, etc. that you
will end up mucking things up and achieving less effective access control
than you would have had you used coarser grained access control.

"I think, for example, that the Principle Of Least Privilege has done an
enormous amount of damage to security because what it encourages
you to do is to make everything fine grain and work out all the
dependencies very carefully and it's too complicated.  You can't keep
track of it.  You're bound to mess it up.  Even if you get it right today
it will be wrong three months from now.  Nobody will have the patience
to ever look at it again because there's just too much of it.  So I say
absolutely no to fine grain protection.  Everything should be as course
grain as possible because otherwise you won't be able to administer it.
That's a very unpopular position with most people.  I think there's a lot
of empirical evidence that tells us now that it's right."

I don't agree with his position.  I believe simple binding of permissions with
passed parameters (capabilities) is actually simpler and less likely to cause
administrative complexity than even coarse grained ACL identity based access
control management.

We (the capability community) have to make convincing arguments, 
etc. in this area to swing people over to our position (or not...).

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20061128/6bf7b5c8/attachment-0001.html 

More information about the cap-talk mailing list