[cap-talk] gauntlet - one way IPC considered useless, practical MLS?

[Rob J Meijer]

> Rob J Meijer wrote:
>>>I wrote:
>>>
>>>>Suppose that a process A wants to tell processes B and C to perform
>>>> some
>>>>actions P_B and P_C respectively, and be assured that all effects of
>>>> P_B
>>>>happen before effects of P_C. B and C do not know anything about each
>>>> other.
>>>>There are only a few possible ways to implement this:
>>
>> If you remember that:
>>
>> a) Two way comunication channels can be composed of two one way
>>    communication channels.
>> b) B could in time exist as different incarnations.
>> c) incarnations of B can have a one-way IPC channel to A for as long
>>    as they don't read any secret.
>> d) Only on reading a secret would the B->A channel be revoked.
>> e) If a B incarnation chooses to it can have itself die and be respawned
>>    with the B->A channel restored in the next incarnation but with non
>> of
>>    its possible secret related state intact.
>>
>> than you would see that the problem is actualy much smaller than you
>> think it is. Dropping state time and time again is expensive, but it is
>> a solution.
>
> It is a solution in some cases. What about all the cases in which it is
> not, because B needs to retain its state?

If B only needs to retain its state from before it read the secret, than
simple paterns suffice and multiple rather standard options are available.
If B needs to retain its state 'after' it has read the secret, than B
either needs to permanently drop its B->A channel, or B needs to be
promoted to a trusted
subsystem. Promoting subsystems to trusted subsystems is something that
is in general rather expensive as it involves extensive code audits,
dedicated resource pools and a lot of things you generaly learn you
want to avoid after having gone truegh the process ones or twice.

>
> I don't think I'm overestimating the problem of building an entire system
> using the techniques you're suggesting, at all. The costs, in terms of
> complexity, unreliability and inefficiency, are enormous, and the benefits
> too small.

The simple fact is that fully persistent two way communication is
incompatible with untrusted (that is un-audited, not unknown) handling any
secret. A second fact is that promoting code to a 'trusted' level is
exceptionaly expensive for anything but the most trivial re-usable
components. These two facts combined make that any practical system
that works with clasifications of data will need to use one-way
communication channels at some points in their design.
In my experience the added complexity with one-way channels is an
acceptable payment for avoiding or minimizing code audits, that I believe
are much more expensive given the complexity involved with proofing fully
connected and interconnected subsystems to enforce the required policies
by subjecting
the system design and the resulting code to a full scale certifying auditing
process.

Rob