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

Valerio Bellizzomi devbox at selnet.org
Tue Nov 28 17:38:26 CST 2006


On 28/11/2006, at 13.49, Jed at Webstart wrote:

>At 01:11 PM 11/28/2006, Valerio Bellizzomi wrote:
>>On 27/11/2006, at 14.59, Jed at Webstart wrote:
>>
>><snip>
>> >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.

It is a question of standpoints, define "unreasonable".

>
>> >>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
>>here.
>
>I agree.

I think we can postpone this too.

>
>>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
>operation."

The meaning is Atomic action kernel: setup phase -> commit point -> action
phase.
The action phase either succeeds entirely or fails entirely, this is the
notion of "atomic" as Shap defines it.

>
>> >><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.

You said copying isn't like sharing because you can't read future changes,
so proxying isn't sharing. I agree, but now you say that proxying is a
means to do sharing, you need to pick a consistent position here.

>
>><snip>
>> >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
>>posterity.
>>
>>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.

I believe limiting shared resource is one of the objectives of Shap's
research (read the "Debunking Linus's Latest" and "From EROS to
Coyotos/BitC: Open Source meets Open Proofs" papers). I think we have to
sit down and wait that Coyotos is ready for prime time. Meanwhile I
continue to learn BitC at least theorically, until I put myself in
condition to build the compiler (which means installing FC6 and the
Coyotos development tree on a new machine) and start programming.

>
>><snip>
>> >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
>>flags.
>
>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.
>
>Lampson:
>"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.

But we agree on this point, why are we reiterating it over and over ?

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

I'm not a fan of pure theoric demos, I think we should start using
capability systems in our daily work, and then show that they really work
very well for us. This would be the better demonstration we can do.

val

>
>--Jed http://www.webstart.com/jed/ 
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk





More information about the cap-talk mailing list