🚀 go-pugleaf

On Mon, 17 Aug 1992 17:51:23 GMT, mark@hpcvxmsr.cv.hp.com (Mark Rowe) said:
> It is true that properly implemented MAC would prevent the use of my
> example.  That does not in any way prevent this from being an example
> of a covert channel, it's simply a covert channel that can be eliminated
> by MAC.  

Wrong, bucko! If properly implemented access controls would close the channel,
then the channel is a *flaw*, not a covert channel.

> MAC does not define a covert channel.  

I'd agree with you on this; however, covert channels other than MAC-type ones
aren't interesting. Why would I care about a DAC covert channel, when I just
just exploit the weaknesses inherent in DAC.

> What defines a covert
> channel is how the data is being transmitted.  It is either overt or
> covert.  An overt channel is a channel that transmits data in a known
> manner as intended by the system administrators.  A covert channel is
> anything else.

Judging intent, however, is quite difficult. Let's take some examples here.
Suppose I have a system where I can observe contention for a system resource,
say memory. I exploit this to transmit information. That's a clear channel.
Other cases aren't so clear. Look at Unix. There are many ways I can
communicate with processes. Are signals a covert channel? Is the use of ptrace
a covert channel? Is the use of the process number address space a covert
channel? 

It's not always so clear cut (alas).

Daniel
--
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
   "You can't be a rationalist in an irrational world. It isn't rational!"
	       Dr. Rance, in Joe Orton's "What the Butler Saw"