Re: Information Flow



On Sun, 23 May 2004 15:03:41 -0400 (EDT), Magosányi Árpád
<mag@bunuel.tii.matav.hu> said: 

> 2004-05-06, cs keltezéssel 21:35-kor NIAP Interpretations Board ezt
> írta:

>> 1. There appears to be a misunderstanding about the term "illicit
>> information flow". This term (which in Part 3 is called a "Covert Channel")
>> refers to channels that can signal information in a fashion to circumvent
>> policy. [....]

>> Buffer overflows typically do not 
>> signal information in that fashion. 

> The misunderstanding is in your part. I wanted to point out that flow of
> control information is also information flow, and buffer overflows are
> a class of illicit information flows. Think network protocols or
> message passing in microcernels to understand the world view where
> you have control and payload data, and both flows. Now look at anything
> else from that viewpoint.

Ah, you misunderstood what was written.

In the classic sense (i.e., think a Mandatory Access Control policy, where you
have labelled data, for example, Trade Secret (TS), Sensitive (S), and
Uncontrolled (U)). Your normal covert channel (illicit information flow) is
something that allows signalling from high (eg, TS) to low (U). For example:

o A TS user may use up all file handles in the system, with a bit of
information being transmitted by the error code that no more handles are
available.

o A TS user might transmit lots of data on a shared bus, thus slowing down the
data rate of the U user.

In this classic case, your normal buffer overflow is not a covert channel
because the buffer is local to a particular process, that is, it cannot be
used to signal high to low.

When you start talking about network protocols and such, you are talking about
a DIFFERENT information flow policy, such as one that controls subject to
subject data flows, as might be found in a firewall. In such a policy, yes, a
buffer overflow might be an illicit information flow, for that might allow a
flow of data in opposition to policy.

So, I think we are in violent agreement.

Daniel






Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov