[cap-talk] The Cascade Problem viewed as a Permission vs. Authority Distinction

[Toby Murray]

Hi cap-talk,

A question for anyone more familiar with modelling security properties. 
I'm currently working through a paper "Multilevel Security and Quality 
of Protection" that looks at reasoning about multilevel secure systems 
in terms of quality of protection. Formal reasoning about security 
properties is something I'm fairly interested in but have virtually no 
knowledge in.

In the paper, they describe "The Cascade Problem" and give an example 
based on the Chinese Wall policy. I understand this problem has been 
extensively researched in the past. From my point-of-view, it has some 
stong parallels with the "Permission-only Analysis" problem discussed 
previously on this list.

The example from the paper is as follows:

A financial system manages accounts for a number of organisations. Data 
is labelled with names such as "hp", "ibm" "shell" etc. Each component 
of the system is given an assurance rating. Ratings include "consultant" 
and "overseer". Components with rating "consultant" are not allowed to 
access data could bring about a potential conflict of interest. As such, 
"consultant" components can't access both "hp" and "ibm" data but can 
access both "ibm" and "shell" data or both "hp" and "shell" data, for 
example.

The cascade problem comes about when two components, A and B, are 
composed that both have the "consultant" assurance rating. Component A 
is allowed to access "ibm" and "shell" data. Component B is allowed to 
access "hp" and "shell" data. When these two components are composed 
(because they need to work together on some "shell" accounts, for 
example) they are permitted to share "shell" information.

The paper puts it like this:
There is a cascading path from "ibm" on entity A to "hp" on entity B via 
shared channel  "shell". The assurance rules require an assurance level 
of at least "overseer" in order to be able to simultaneously access botg 
"hp" and "ibm" information. However, with a configuration that allows A 
and B to share "shell" information, entities with an assurance rating of 
just "consultant" can obtain this access.

To me, it looks like a classic permission vs. authority analysis 
problem. In cap-talk lingo: By the permission rules, both A and B are 
correct. But once composed, we don't trust either not to share part of 
their own authority with the other (by proxying).

I haven't yet read through the rest of the paper but I was curious to 
find that the same sorts of problems discussed on this list in terms of 
the permission vs. authority distinction are able to be captured by the 
sort of model they use in thier paper. I would be interested to get the 
toughts of anyone out there who's more across this stuff than I, 
particularly whether my above charactisation of this problem as a 
permission vs. authority distionction is valid.

Thanks,
Toby


-- 
Toby Murray
Advanced Computer Capabilities Group
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.