blob: 4def1b87eff6224a825825d9b13a904804f5f96b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
Interference can be destructive or non-destructive. When a principal
invokes an object (thereby requesting a service) and the implementation
carries out the principal's intent, the interference was non-destructive
in the sense that the interference was desired.
In invoking the object, the principal may make itself vulnerable to
destructive interference. When a user runs Solitaire on Windows,
the Solitaire program is instantiated and given all of the user's
authority. The program may delete all of the users files after
publishing credit card and other sensitive information on the Internet.
This type of interference is undesirable, however, generally practically
unavoidable due to the way programs work on Windows (and Unix, for that
matter).
The problem is that the callee has induced negative consequence for caller
due to actions of the former. To not have to depend on another program (and
thereby not have to add it to its [[tcb]]), it is necessary that the
caller only make itself vulnerable to destructive inference in ways that
can be detected and from which it can recover.
Mark Miller examines the idea of destructive interference in his PhD thesis
[Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control](http://www.erights.org/talks/thesis/).
|
