Factory Pitfall

[Ben Laurie]

Bill Frantz wrote:
> 
> At 10:43 AM 12/24/98 +0000, Ben Laurie wrote:
> >Hmmm ... do you think it is possible to avoid covert channels?
> 
> [#] Our (the KeyKOS group's) analysis indicated that it was possible to
> greatly limit the bandwidth of covert channels.  Norm alluded to a covert
> channel where the sender and receiver share some limited resource (e.g.
> disk space).  By statically allocating separate pools to the sender and the
> receiver, you eliminate that channel.
> 
> It turns out that timing channels are the hardest to eliminate.  KeyKOS was
> originally written for the IBM S/370.  That machine has a user-mode
> accessible clock which ticks at approximately the clock rate of the CPU.
> It makes a wonderful tool for performance tuning, and for using CPU usage
> as a covert channel.  In general, you have to restrict access to the clock
> to eliminate this kind of covert channel.  If you limit the precision of
> the clock, you limit the bandwidth of the channel but do not eliminate it.

It was precisely this kind of channel I was thinking of when I asked the
question, though it seems to me that the solution is the same as the
solution for storage - static allocation of CPU usage.

However, surely the problem is that this means that I have to decide in
advance that I will support at most n processes, and divide every
resource into n chunks in advance, and _stick_ to that division. Which
may give me security, but at hellish expense.

> Some of the work in "reproducible computing" applies to this problem.  If
> you build a system where programs always run the same way, only dependent
> on their user specified inputs, then you eliminate them as receivers of
> covert channel information.  This is much harder than it may at first seem.
>  You must ensure that thread switches and interrupts occur at the same
> place in the instruction stream every execution.  In general, it is
> necessary to eliminate interrupts and thread/process interactions to
> achieve this level of reproducibility.

Doesn't that effectively mean we're talking about a purely theoretical
system?

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author     http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache/