🚀 go-pugleaf

In article <20477@optima.cs.arizona.edu>, ho@cs.arizona.edu (Hilarie Orman) writes:
|> In article <1992Aug12.204649.4110@osf.org>, karger@osf.org (Paul A.
|> Karger) writes: 
|> > Covert channels involve illicit communications between two processes,
|> > a transmitter process that is running a Trojan horse, and a receiver
|> > process that belongs to a spy.
|> 
|> You seem to imply that it can't be a covert channel without intent.
|> I've always relied on the notion of information flow - if the writer
|> of the transmitter program did not specify the information as an
|> output, and if a receiver program can detect the information, then you
|> have a covert channel, a concept further divided into storage and
|> timing channels.
|> 
|> If you don't agree, what alternate term would you use to describe the
|> password inference problem originally described?

Covert channels are only of interest when there is intent.  The password 
inference problem from the page faults on TOPS-20 was an argument validation
problem.  Argument validation says (among many other things) that you
should COPY your arguments from user space into kernel space to avoid
asynchronous attacks.  TOPS-20 wasn't bothering to do the copy.

Not everything is a covert channel.   Many classes of operating system
penetrations reveal information that the O/S did not intend to reveal, but
those are not covert channels.  They are operating system security flaws.
Covert channels specifically involve a Trojan horse in untrusted code 
running at a high security level causing information to flow to a spy at
a low security level.  An operating system flaw that allows me to run
kernel-mode code of my choice certainly can lead to improper information
flow, but it isn't a covert channel.

	- Paul