[cap-talk] Wall banging (was: Bellizzomi, Capabilities, Shapiro's focus, Coyotos, etc.)
Jed at Webstart
donnelley1 at webstart.com
Wed Nov 29 20:14:35 CST 2006
Thanks for the review in the messages below. I agree with what I
read as Jonathan Shapiro's sentiment that one needn't worry about
dealing with covert channels while there are overt channels available
and no means to prevent them.
Can anyone tell me if there any systems where overt channels have
been sufficiently controlled that time/effort have been spent working on
controlling covert channels (e.g. by restricting the sorts of non deterministic
inputs available to some set of programs/processes)?
I had imagined that the concern about wall listening was mainly
for cases where the program was a black box (e.g. proprietary code).
Once you get to the point of auditing source code it seems to me that
the costs are so high and the means of control so good that worrying
about non deterministic inputs is likely a small part of the problem.
Does anyone know of discussion of controls (e.g. process limits
like no parallel, no clock, etc., etc.) that have been practically
made available in systems to more safely run black box code
so as to more likely be safe from wall listening?
At 12:36 PM 11/29/2006, David Wagner wrote:
>Toby Murray writes:
> >On Wed, 2006-11-29 at 10:31 -0600, Karp, Alan H wrote:
> >> While you can't prevent wall banging, you can prevent wall listening by
> >> removing all forms of indeterminacy, such as access to the system clock.
> >> Any process that is deterministically replayable meets this criterion.
> >Are there generally accepted definitions for "indeterminacy" and
> >"deterministically replayable"? If so, how do these definitions relate
> >to non-interference? At first glance, it would seem that they are
> >intrinsically linked to me.
>Deterministically replayable: ...
>Transforming a program ...
>Deterministic processes are unable to listen to covert channels...
>...However, transforming a program into d.r. form may aid covert
>channel analysis ...
>Non-interference is trickier...
At 02:17 PM 11/29/2006, Mark Miller wrote:
>...Alan and I are only claiming that
>we can *prevent* wall listening, and only for those jobs that don't
>need dangerous sources of non-determinism, such as
>*) any interactive access to the outside world, or
>*) the ability to read the clock, or
>*) the ability to spawn internal process which can run internal races.
>A word processor cannot be deafened, because it need to interact with
>a user. A compiler can be deafened. I suspect most programs are in the
>*cannot be deafened* category, but perhaps enough programs can be
>deafened that they can be used to take up the resource utilization
>slack I explained before -- if one wants to try to imperfectly inhibit
More information about the cap-talk