[cap-talk] automatic policy embodiment and enforcement

Mon Sep 20 03:53:53 EDT 2004

Jed Donnelley wrote:

> There are several aspects of the exchange below that puzzle me.  
> Perhaps there's some context that I'm
> missing that somebody might be able to fill in for me.
>
> Perhaps I can start with Toby Murray's statement, "...we'll have to be 
> able to build these abstractions and
> generate propagation rules automatically that can be enforced by 
> trusted code, if capability systems are to
> become practical."  I believe there have been numerous capability 
> systems already in the past that have
> proven 'practical' (as I understand the meaning of that term in this 
> context - at least to include security/
> integrity substantially greater than comparable non-capability 
> systems).  They've done this without a need
> for an "automatic mapping of an abstract policy specification".  
> They've done it simply by providing a
> better approximation of the principle of least access - as discussed 
> numerous times on this list.  One
> application at a time.

"Pracitcal" was a poor choice of word, since it is incredibly subjective.
At the most basic level, what I made the statement, I was really talking 
about being able to take some abstract policy and being able to come up 
with (say, for an object-capability sytem) a specification that includes 
a number of object type definitions and some instatiation of those types 
(which are really just a number of abstrctions on the base system). If 
these objects are trusted to enforce policy, then the definition of 
these types and the initial instation implicitly defines what can and 
cannot be done within the system and how authority may propagate (ie. 
the policy). Since  an object capability sytem allows practically 
arbitrary constructions from the base building blocks (objects), it is 
non trivial to say whether some construction enforces some policy. I was 
wondering what work to date has looked at this area.

>
> Of course transitioning from the current environment of Unix and 
> Windows dominated systems to some
> sort of capability based operating systems is a huge practical 
> problem, but I don't believe that problem
> is significantly related to a need for the ability to build trusted 
> abstractions and to enforce security policy
> via policy abstractions by automatically propagated rules generated 
> from them.  My feeling is that
> such abstractions would likely be too high level to provide much 
> benefit on practical security/integrity.
> Be that as it may, I don't believe any need for such automated 
> propagation of abstract rules has a
> substantive impact on the practicality or non practicality of 
> capability based systems.
>
when I said propagation, I mean propagation of authority (either 
explicit via propagation of capabilities, or implicit by proxying and 
the right to communicate). 

> Then regarding Norman's response:  It does seem obvious that the 
> closer approximation to principle
> of least access privilege management that KeyKos provided(s?) would 
> make it more resistant to viruses.
> In so far as the Orange Book addressed itself to that issue, I can see 
> how the protections provided in
> KeyKos would be viewed as providing added value (e.g. as I claim for 
> many such past capability based
> systems).  However, was there something in Toby Murray's message that 
> suggested he was concerned
> specifically with Orange Book specified protections (other than 
> perhaps his signature from a defense
> related organization) or with protection from viruses?  Toby Murray's 
> message (as I understood it) was
> making the claim that generally accepted abstract policy 
> specifications must be agreed upon
> and automated means must be available to propagate their rules before 
> capability systems with
> be "practical".  I don't agree with that statement (as I've noted), 
> but I was a bit at a loss to know
> how to respond except by example (which seemed a bit pointless as the 
> examples are obvious
> and well known).  Of course KeyKos is such an example, but so are 
> nearly all other previous
> capability based systems - even without such automated propagation of 
> abstract rule sets.
>
> Since there seemed to me something of a disconnect between the initial 
> message and the response

potentially. The Organge Book and viruses, while a very useful example, 
are a limited frame from which to view my comments -- I was talking more 
generally. Of course, like all things, the less constraints, usually the 
more difficult the problem.

>
> (though I admit that I understand the initial question less than I do 
> the response), I thought I would
> try to frame both messages a bit along the lines of my thinking and 
> see if I could get help making
> sense of this initiated dialog.
>
> Thanks for any help with clarification.
>
> At 06:46 AM 9/19/2004, Norman Hardy wrote:
>
>> The paper at 
>> <http://www.agorics.com/Library/KeyKos/keysafe/Keysafe.html> provides 
>> a fairly detailed design of a system that was meant to address the 
>> main points of the Orange Book and its concepts of security labels 
>> that were attached to data.
>> Such software was not built for lack of specific contracts.
>>
>> Some from the military community were convinced that designs along 
>> these lines would meet their needs both in the letter and spirit of 
>> the Orange Book.
>>
>> One of the key points is that just as a secure system need not attach 
>> a label to each value transferred between registers, neither does it 
>> need to attach a label to each message transferred between protection 
>> domains is a capability system. In each case the perimeters relevant 
>> to labels are coarser than the individual data transfers.
>>
>> While the Orange Book was probably written assuming that all of the 
>> security enforcing logic would be in some kernel, to its credit it 
>> did not actually say so. The NCSC team that examined Keykos was 
>> pleased that the security policies they were concerned with would be 
>> implemented in a flexible environment. They did not think that the 
>> Orange Book was the last word in the required security policies. They 
>> recognized that the Orange Book was silent on the issue of viruses, 
>> presumably because it was seen as too much to require.
>> They recognized that the virus resistance provided by Keykos would 
>> provide a significant advantage over systems that merely met the 
>> Orange Book requirements.
>>
>> On Aug 10, 2004, at 6:22 PM, Toby Murray wrote:
>>
>>> In my reading of literature regarding capability systems and 
>>> implementations I'm yet to find any work that deals with the 
>>> automatic mapping of an abstract policy specification (in whatever 
>>> appropriate paradigm) to rules regarding capability propagation 
>>> between entities, and trusted abstractions built over the base 
>>> system. While it has recnetly been explicitly recognised in the 
>>> literature (at least from my understanding) that trusted 
>>> abstractions enforce security as well (and therefore are an 
>>> embodiment of the policy) -- with the decisions regarding 
>>> distribution of capabilities between entities being the other 
>>> embodiment of policy --  it appears that we'll have to be able to 
>>> build these abstractions and generate propagation rules 
>>> automatically that can be enforced by trusted code, if capability 
>>> systems are to become practical.
>>> Perhaps capability systems make this problem harder because they 
>>> allow almost arbitrary security paradigms (in which any policy must 
>>> be framed) to be mapped onto the base system. (eg. we can do RBAC or 
>>> Bell-LaPadula if we want to build the right abstractions and come up 
>>> with the right rules etc.) We have seen very small examples here and 
>>> there (eg. indirection for temporal revocation, and the example used 
>>> by Shapiro et. al to show that the *-property can be enforced), but 
>>> all of these must be crafted by a human who "knows" that the 
>>> abstraction and associated rules actuall embody and enforce the 
>>> abstract policy.
>>> Has any work been done in this area and if so could someone point me 
>>> in the right direction?
>>>
>>> Thanks,
>>> Toby
>>>
>>> -- 
>>> Toby Murray
>>> Software Engineer
>>> Advanced Computer Capabilities Unit
>>> Information Networks Division
>>> DSTO, Australia
>>>
>>> IMPORTANT: This e-mail remains the property of the Australian Defence
>>> Organisation and is subject to the jurisdiction of section 70 of the
>>> Crimes Act 1914. If you have received this e-mail in error, you are
>>> requested to contact the sender and delete the e-mail.
>>>
>>> _______________________________________________
>>> cap-talk mailing list
>>> cap-talk at mail.eros-os.org
>>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
>>
>> _______________________________________________
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk

-- 
Toby Murray
Software Engineer
Advanced Computer Capabilities Unit
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.