blob: b6c803259ba22b2c9fee72c94b9218b7a66e72e7 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
[[license text="""
Copyright © 2007 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.2 or any later version
published by the Free Software Foundation; with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included
in the section entitled [[GNU_Free_Documentation_License|/fdl.txt]].
"""]]
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/).
|
