[cap-talk] Confinement CC problem ??

[Rob]

> Rob wrote:
>>>>>In my proposed design the capabilities are being locked down
>>>>>to a clearance level instead, allowing processes with capabilities on
>>>>>multiple clearance levels to somewhat move between the levels during
>>>>>their lifetime. [...]
>>>
>>>http://www.xs4all.nl/~rmeijer/tsproxy/
>>>
> [...]
>> The discussion seems to have died out. However it would I think be very
>> important if we could resolve the issue. If as I think we can indeed
>> define a confinement subset of the CC problem in a way as described
>> abouve, this could potentialy be a big step forward in getting cap
>> design
>> accepted as alternative in governmental military and law enforcement
>> organisations. If on the other hand I am fundamentaly misguided in my
>> assumptions, I could stop wasting any more time in attempting to do so.
>>
>> Please look at the abouve URL and try to understand what I am trying to
>> do and if the definition of a confinement subset of the CC problem would
>> indeed be possible in a way like this.
>
> I think that defining confinement in terms of clearances is fundamentally
> the wrong approach, whether or not it is possible.
>
> To the extent that any governmental, military or law enforcement
> organisations
> consider clearance levels and/or variants of the *-problem to be the right
> way to model their information security requirements, I believe they are
> mistaken. Developing complex extensions of capability systems to attempt
> to
> handle security policy in those terms would be a misdirection of
> resources.

I dont know about the rest of the world, but over here unfortunately there
are official guidelines mandating compliance to this type of modeling for
govermental military and law enforcement organisations.

I strongly believe that in many cases of system design, clean capability
based design would yield better more secure solutions that would adhere
to the given data confinement goals that lay behind the official
national guidelines, and there in theory are ways that such systems could
be aproved for actual usage. The problem is that in practice the way to
get the design, let alone the implementation accepted involves a difficult
and lengthy certification track that by its very mentioning is enough
for lower management to kill a project in its infancy.

Let me try to scetch the theoretical path that any simple capability based
system design enforcing the required confinement of clasified data would
entail, perhaps you than understand the problem.

* After design, the design is inspected, and givven that it spawns
  multiple levels of data clasification, as defined in the official
  guidelines, this inspection marks sections of the design as
  something like 'untrusted declasification' given that without
  thourough inspection, it could do inproper declasification.
* If the section of the design does no actual declasification, we need to
  get the 'design' officialy 'audited' only to get the section of
  the design marked as 'trusted subsystem', before we can start building it.
* During implementation we potentialy get confined to the usage of
  specific versions of specific compilers, and some more unplessant
  restrictions.
* After implementation, before we are allowed to use it, the 'trusted
  subsystem' implementation needs to be officialy audited to confirm that
  it is build in confirmance to the design.

As you can see, the path alone is enough to make anyone quickly turn back
to the imho less secure and certainly less flexible use of clasic MLS and
MA systems. That is not even getting into discussing the issues involved
of convincing a long hyrarchy of managers that the trusted subsystem is
of such important to warant this track with an understaffed governmental
auditing organisation.

The main thing I am trying to do is see if we can define a
generic and reusable membrane or proxy patern and implementation that can
be fitted to the 'untrusted declasification' parts of 'any' capability
based design in order to be able to replace the formal official audits by
design
and code inspection, by moving the problematic part into a generic reusable
'trusted subsystem'.

That would mean the membrane or proxy patern would if the design and code
reviews are done properly not have any added security, but in the event
a design or implementation mistake slipped truegh, the system will just
stop working without braking the security policies, thus the strict
requirement of formal audits on design and implementation of trusted
subsystems would be diverted to the reusable proxy patern implementation.

Thus I strongly believe that the question 'if it is possible' is what
needs to be answered, as if it is possible, it is crucial to get it build
and audited in order to enable capability design to take root in
organisations like this. I think this would than be much more realistic
than trying to change the official formal requirements of whole nations,
what I actualy do believe would be best if it would be feasable.

If it is not possible to thus define a Confinement subset of the CC problem,
than indeed it would be a large waste of resources to try to build such a
generic one-size-fits-all capability 'trusted subsystem', but if it
is possible it would be well worth the trouble.

Rob