[cap-talk] Throwing down the gauntlet

[John C. McCabe-Dansted]

On Friday 13 January 2006 09:37, Jed at Webstart wrote:
> At 02:53 PM 1/9/2006, John C. McCabe-Dansted wrote:
> >On Tuesday 10 January 2006 08:00, David Wagner wrote:
> > > John C. McCabe-Dansted writes:
> > > >public:Bob knows that secret:Bob is able to receive at least x units
> > > > of data per second, and will only transmit at this rate.
> > >
> > > I don't understand why anyone thinks that limiting the bandwidth of
> > > covert channels is a very useful solution.
> >
> >Here I am talking about limiting the rate of *overt* communication. Since
> > no back chat is allowed, secret:Bob cannot send flow control signals to
> > public:Bob. Thus it is wise for public:Bob to limit its rate of
> > transmission based on the published realtime constraints of any Bob
> > object.
>
> The above seems to assume that public:Bob wishes to limit the
> communication from secret:Bob.  Isn't the situation we are concerned
> about is where public:Bob wishes to maximize the communication
> from secret:Bob?

public:Bob wants to send a message, reliably, to secret:Bob.

Since we do not allow any messages to be sent from public to secret (or at 
least not by an untrusted application like Bob), Bob cannot rely on ACKs. 

David Wagner suggested that it is impossible to write reliable software 
without bidirectional communication. I am not yet convinced this is the case.

> I agree with David Wagner on this.  I don't see much value in limiting
> the bandwidth of 'covert' channels.  

On this I agree with David Wagner, more or less.  100 bits/sec could leak 
information quite quickly, leaking a single yes/no question (bit) may be one 
bit too much.

> If you can't eliminate them, what's 
> the point of the exercise?  I believe air gaps have proven pretty
> effective. 

True, but in theory adding a transmitter to "public" and a reciever to 
"secret" does not decrease the security of the system. The other question is, 
is this useful?

It seems that even if the hardware is physically incapable of sending any ACKs 
back you could use error correcting codes etc. to ensure that the 
communication is reliable enough. 

On top of that layer it seems that we could implement pretty much every thing 
one would think that an MLS system should be able to support.

Read Lower Log/Spools (e.g. mail inbox): Transmit all additions to the public 
spool to secret and perhaps retransmit later in case something got lost. 
Secret keeps a mirrored copy of the spool.

Read Lower Database: Follow the database log file and recreate a local copy of 
the databate (I implemented a database backup system this way).

Multilevel Database: I haven't had experience with these, but you could e.g. 
disallow writes to public records (so you don't end up with multiple versions 
of the same record), intersperse atomic operations read from the Public log 
with atomic actions received from other Secret processes, and only delete 
Public records from the Secret version of the database when no Secret record 
refers to them anymore. This might be enough.

Cut-and-paste: Each cut operation a user performs copies the clipboard to the 
same users clipboard (with the same session id) at each higher security level 
at which the user operates. So user can press Cntl-C on a public rated 
terminal and press Cntl-V on a linked secret terminal. As mentioned before 

Although it seems to me that these operations could be implemented reliably, 
even if they fail, the worse case is that you end up with a air-gap.

> At least they allow one to focus on what is typically the real 
> problem, the people.  I believe all the MLS machinations within systems can
> help somewhat to keep people/programs from making unintended mistakes
> (as we did with our MLS system), but I think it would be quite unwise
> to trust such systems with a direct connection to, say, the Internet.

If the system is limited so that there is no hardware support for transmitting 
from a Secret node to a Public node, it may be safe to connect Public to the 
internet. That way you could still read mail and feeds from a Secret terminal  
(you'd just have to subscribe & reply from a public terminal). 

> If 
> you aren't going to get to that point, what value is there in pushing on
> things like limiting the bandwidth of covert channels?


-- 
John C. McCabe-Dansted
Masters Student