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
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: email@example.com |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/