[e-lang] On the Value of Covert Channel Analysis

[Jonathan S. Shapiro]

Strong words follow. Perhaps they will clarify things for MarkM, or
perhaps his response will clarify things for me. Either is a good
outcome, but if we are to achieve either we must speak from a commonly
informed lexicon -- much as we needed to do so in the MLS discussion.


	-shap

On Thu, 2002-05-30 at 13:59, Mark S. Miller wrote:
> At 06:06 AM 5/30/2002 Thursday, Jonathan S. Shapiro wrote:
> >In the past, there have been harsh words on this list about covert
> >channel issues. While we should not obsess about them, I would like to
> >make a case for why we should not ignore them.
> 
> To be clear: I'm for ignoring the not-practically-solvable half of the 
> problem -- an outward covert channel leaking bits to an unconfined 
> conspirator.

The objective of covert channel analysis is not and never has been total
prevention of outward covert leakage. That is a laudable goal, but it is
a different objective deserving of a different name. In the text below I
refer to it (purely for lack of a better name) as the "determinism"
goal.

In the context of covert channels, it's now pretty well shown in the
literature that meaningful controls are feasible on both ends (inward
and outward) of the channel, given this, can you substantiate your
assertion that this problem is not practically solvable?

The objective of covert channel analysis is (a) to *understand* the rate
of such leakage, and (b) to reduce it insofar as reduction is possible.
Covert channel analysis is therefore concerned with both inward and
outward leakage. Both objectives clearly and demonstrably *can* be
satisfied by suitable design work, in exactly the sense that
capability-based confinement is solvable: both have been demonstrated in
real, working systems with strong formal foundations underpinning those
implementations.

> When we start talking about 'bandwidth limits', we're admitting we can't 
> actually solve the problem.

Nonsense. As I say above, covert channels and deterministic execution
are different problems. Where determinism is possible, *wonderful*.
Where it is not (see below), we still need to address covert bandwidth.
Let us not confuse terms and thereby make false arguments. It damages
our collective credibility.

> In the meantime, the corresponding solvable 
> problem is mostly unmentioned and ignored.

We do agree that where determinism is feasible it can and should be
applied. It is not feasible in all situations. It is not feasible in
*any* situation where conventional multithreading or multitasking
exists, for example. This means it is not feasible wherever a
bidirectional stream exists. E avoids this by implementing some special
cases in the runtime, but this is an (admittedly brilliant) incomplete
escape hatch.

> The high assurance level criteria are then doubly wrong -- once to
> insist on bandwidth limits on the outward side, causing effort to
> be spent needlessly, and again not to insist that the inward
> problem be solved,...

You really need to read the standard before you dump on it.

The applicable standards do not say this, and have not done so for
years. The description above is not even an accurate characterization of
the Orange Book requirements. On the subject of covert channels, current
applicable standards (the Common Criteria, CC) require analysis and
reduction of covert bandwidth without reference to whether the data
motion is inward or outward. It is considered a satisfactory approach to
limit all inward covert channels, because in doing so one necessarily
has limited all outward covert channels. The problems are strict duals;
the inward/outward feasibility distinction you are insisting on does not
actually exist in the covert channel problem -- only in the determinism
problem.

In the general case, determinism simply isn't an option from a
functional requirements perspective, so the standard cannot and does not
insist on it. CC requires both security and functional requirements to
be addressed. The failure in the CC standard, if there is one, is that
it does not require that abandonment of determinism and the consequent
exposures must be justified w.r.t. the total set of requirements for the
software artifact. This probably *is* a failing, and it should perhaps
be examined at the next CC standards body meeting.

Perhaps you could cite the CC standard sections that you are objecting
to. I believe you will be unable to do so w.r.t. your assertions above,
and that until you *can* do so you should withdraw the assertions. When
I get a minute I will try to write a synopsis -- it may be a week or
two.

> ... thereby not directing effort to where it 
> could do some good.

Empirically, the effort has done *great* good. If you believe otherwise,
please kindly (1.a) read the standards so you know what you are arguing
against, (1.b) read the relevant papers that I have pointed to twice now
(Oakland 1991; the are four papers on this subject are considered pretty
definitive), and (1.c) refute them, or (2) withdraw this assertion. Your
line of argument on covert channels as I understand it to date is
exactly the type of argument that Earl Boebert made about capability
non-confinement -- and appears to be just as wrong.

Note once again: I agree that the determinism approach deserves
attention at both standards and practical levels.

> >Covert channels are a mixed bag. One wants to avoid introducing them
> >stupidly -- the clipboard being a case in point (I could argue that this
> >is an authorized, and therefore overt, channel, and the cut/paste
> >scenario is in fact a failure of POLA). 
> 
> I would argue so as well.  This is so clearly an overt channel, and the bad 
> clipboard policies we discussed so clearly a violation of POLA, that I'm 
> puzzled why you raise it in this context.  I certainly believe that we must 
> bring the clipboard under proper capability & POLA discipline, and that 
> MarcS's powerbox, and your picture of how to do the equivalent under EROS, 
> does this well.

There are actually two channels in the clipboard as customarily
implemented. The first -- the clipboard channel -- is an overt channel.
The second -- the "clipboard changed" event -- is definitely overt, and
is the more subtle one to solve.

> I agree with this list, so long as we don't take #4 to mean "formal 
> verification according to criteria specified by some standards committee, 
> and which we do not believe in."

I believe that the most you can safely say is "*I* do not believe in
*something I imagine that the standard says.*"

> But if by #4 
> you mean EAL7 or Orange Book or something, then I'll postpone worrying about 
> it until the man with seven zeros shows up.

Ahh! The old "I'll deal with the hard security problems later" strategy.
I should think this strategy to be (by now) well tested. Shame on you
for indulging in it. :-)


shap