[cap-talk] Capabilities - the rub (was: NCSC TCSEC)

[Valerio Bellizzomi]

On 09/11/2006, at 17.42, Jed at Webstart wrote:

>(for a briefer read, please skip down to Here's the "rub" (about
>1/2 way through this message)
>
>At 02:37 PM 11/4/2006, Valerio Bellizzomi wrote:
>>On 01/11/2006, at 18.33, Jed at Webstart wrote:
>>...
>> >).  I believe the concerns of the authors about capability systems
>> >are pretty clear, e.g.:
>> >
>> >pp. 3 "merely possessing the capability ... is sufficient proof
>> >that access should be granted.  Note that, if a capability is
>> >ever stolen or given away, this protection mechanism can result
>> >in other subjects accessing the object without incurring a
>> >protection violation.  Thus, special care must be taken to
>> >prevent the use of capabilities that are stolen while migrating
>> >on off-line storage or among different sites of a network
>> >[Nessett82, Donnelley80]"
>>
>>
>>Comparison of "capabilities" with "badges" is apropos, a stolen badge
>>doesn't incur in security violation, but it allows an unauthorized
person
>>to open the door. It is then a question of detecting the theft ASAP, so
>>that the badge can be disabled (i.e. the capability revoked).
>
>and the oft cited "key" metaphor also may be helpful.  To carry the badge
>metaphor a bit further I think the TSEC authors want the sort of badge
that
>identifies a person so that any access can be associated with the
>person (e.g. logged/audited) and controlled via access list.

I assume that capability transfer can be logged.
Of course the "key" metaphor is helpful, but I see the metaphor of "badge"
more pratical here, because a badge can be enabled to open various doors,
and/or to open a door only inside a certain time-slice (time-restricted
capabilities), in addition the "key" does not identifies the person.

>
>>...
>> >I believe this document and a few others like it during this time
>> >were essential in basically killing the object/capability approach
>> >to computer security.  I also believe that any effort we make to
>> >reverse this trend will have to answer the objections in this
>> >and similar documents.
>>
>>But this is an old paper, I believe the "traditional" capability-based
>>system they talk of are also old, it is possible that the *new*
>>"traditional" capability-based systems are different from the old ones.
>
>I don't believe there are any substantive differences.  The authors are
>focusing on the core of the capability paradigm.  Namely the delegation
>mechanism, e.g. as per a Granovetter diagram like:
>
>http://www.erights.org/elib/capability/ode/overview.html
>
>>Anyway I think that the TCSEC requirement 2,
>>
>>"Requirement 2 - MARKING - Access control labels must be associated with
>>objects. In order to control access to information stored in a computer,
>>according to the rules of a mandatory security policy, it must be
possible
>>to mark every object with a label that reliably identifies the object's
>>sensitivity level (e.g., classification), and/or the modes of access
>>accorded those subjects who may potentially access the object."
>>
>>gives the impression that such "labels" are similar to the philosophy of
>>capabilities, except that capabilities identify the object itself (not
its
>>sensitivity level) plus an access mode.
>>A badge is similar to a label too. If a badge is similar to a
capability,
>>a thief can open doors with a stolen badge, but he cannot pass an human
>>security control that verifies the badge visually, bacause a badge
>>identifies also the person to who it is given by a photo and the name of
>>the person.
>>So, is it possible that the "marking" could be used as an element of a
way
>>out of TCSEC, and as an argument to "rebirth" the object/capability
>>approach to computer security?
>
>You didn't seem to address the term "subject" referenced in their quote.
>I believe the subject notion is the key element to their concerns and
>generally the issue for those who successfully oppose capability
>systems in commercial applications.

You are at right, I didn't address the "subject", but this was
semi-intentional, because the computer does not recognize the person, but
recognizes only the username/password couple (unless there is some sort of
identification device such as a fingerprint scanner, but nothing is
absolutely secure...). And passwords can be stolen away just like keys,
badges and capabilities.

>
>Here's the "rub" (as I see it of course).  The people who think along
>TCSEC lines (and they aren't just military and or government and
>MLS people) think in terms of people and what they should have
>access to.
>
>Consider the recent HP board scandal (obvious leak, find the leak,

I'm not aware of it.

>fix it).  If your IT infrastructure runs a typical identity based system
>(think Unix or Windows) you remove his account.  End of problem.
>You might want to know what he (it was a he in this case) did have
>access to for damage control, but at least things aren't going to get
>any worse.

You seem to assume that the system hasn't been compromized, the user could
have installed a trojan horse. It is also possible that another malicious
user collaborates with the first one, so I don't see the end of the
problem.

>
>If you run on a capability infrastructure you can remove the account,
>but then you think, "Oh my gosh, I wonder where he might have
>delegated access to some of the resources he had access to?"
>How do I remove any access that he might have delegated?"

The same thing can happen in an ACL based system since the user could open
access to his files to the "group" or "world", then you are never sure
that his programs aren't copied in someone else's account.

>
>When David Wagner says:
>
>At 03:20 PM 11/4/2006, David Wagner wrote:
>
>>A personal opinion:
>>
>>The TCSEC requirements are most irrelevant to modern computer security
in
>>the commercial world.  They're a waste of time.  Every second you spend
>>trying to comply with TCSEC is one second forever lost from your
lifespan.
>>They're not worth the brain cells; don't bother.
>
>I respectfully disagree.  Perhaps if you focus on the MLS aspects of the
>TCSEC
>we generally agree in this area.  I believe MLS, Bell and LaPadula, etc.
is
>pretty much a mess and likely to stay that way for some time (forever?).
>Perhaps that aspect of the TCSEC can be safely ignored and considered
>irrelevant for "modern computer security in the commercial world."
>
>However, I think the base concern about binding subjects (continue to
think
>people for a while here) to their authorities coupled with the concern
>about
>unrecoverable delegations continues to be relevant and remains at the
heart
>of why the object/capability paradigm is still considered impractical
>(though
>there are other concerns, implementation issues, performance, usability,
>etc.) in 'modern' computer systems.
>
>In a system that uses identity based access control such as Unix, one
>can look at an object (e.g. a file) and say, "Ah, I see who can access
>this file.".  This user (the owner), perhaps people in this group (with
>this
>or that access) and perhaps some access for everybody else on this
>system.  I get all this information from looking at the access
permissions
>associated with the file.  I can directly see which subjects (users) have
>which access to this object.  If I want to find out which resources some
>user has access to, I can also do that fairly easily.  I just check to
see
>which groups this user is in and which resources are either owned by
>that user, are accessible (in whichever way) by some group that user is
>in, or are world accessible (in whatever way).  I seem to have the full
>"access matrix" at hand.

Yes, but the file could be copied/renamed, and also changed if it is a
source code, and the original file deleted, so even with an original-file
signature it isn't sure that you can track it.

>
>How do I do the equivalent operations on an object/capability based
system?
>
>I guess I'll just leave that question hanging out there for a while to
see
>if I
>get responses before I weigh in on the other side of this topic.

The most blatant case of "superuser absolute power" is that it has always
access to your e-mail files...
I hope that it will NOT be necessary to do the equivalent operations on an
object/capability based system. As per the ASP/OS PP at the points
P.OperatorExposure, P.AdminTools, P.PolicyRigor, P.Resource, P.RsrcMux,
and in particular the points SO.NoSuperUser, SO.SeparationOfAllocation,
SO.NonDisclosure, SO.PositiveAgreement, SO.SoundAdministration,
SO.NoDetect, SO.PktFilter, it shouldn't be permitted by the TOE to do such
operations.
I don't take the ASP/OS PP as a gospel.....but if the TOE is going to
comply with it, I don't see how you can do the equivalent operations!

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