Re: Factory Pitfall Ben Laurie (ben@algroup.co.uk)
Thu, 24 Dec 1998 23:23:28 +0000

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/