Information Technology Reference
In-Depth Information
resources, and that handle sensitive information (personal location, contacts,
passwords). This combination demands for scalable and ecient mechanisms for
ensuring privacy in a distributed setting with code mobility. From an abstract
perspective, each device forms a
computation domain
with specific capabilities
and restrictions, and in particular information flow policies for protecting data
and other computing
threads
that are running concurrently in the same domain.
We refer to these policies as the
allowed flow policy
of the domain. Flow pol-
icy confinement ensures that domains do not execute code that might perform
declassifications that break their own allowed policies.
Let us consider, for example, an application for supporting two users (Alice
and Bob) in choosing the best meeting point and path for reaching each other
by means of public transportation. In order to produce advice that takes into
account the current context (recent user locations, trac conditions, weather)
threads containing code for building updated travel maps are downloaded by
Alice and Bob during runtime (their travel). The recommended path and meeting
point can be improved by deducing the users' personal preferences from data that
it collects from the mobile devices (e.g. content of stored images, file types). Users
might, however, have privacy restrictions regarding that data, in the form of
allowed flow policies that the downloaded threads must comply to. The following
naive program creates a thread for gathering data that helps select the meeting
point. Since the meeting point will necessarily be revealed to Bob, this part of
the program should only allowed to run if it respects which private information
Alice accepts to leak to Bob.
1 newthread {
// Creates thread at Alice's device
2
ref zoo=0; ref bookstore=0;
// to choose between zoo or bookstore
3
allowed
// If allowed by Alice's policy
4
(L_IMGS < L_BOB /\
// to leak image contents
5
L_FILES < L_BOB)
// and file types to Bob
6
flow (L_IMGS < L_BOB /\
//
Declares a declassification
7
L_FILES < L_BOB)
//
with same policy
8
processImgs(zoo);
//
weighs images with animals
9
searchFiles(bookstore); //
weighs e-book files
10
if (zoo > bookstore)
//
inspects sensitive data...
11
meetAt(ZOO);
//
and influences meeting point
12
meetAt(BOOKSTORE);
13
meetAt(random);
// If not allowed, uses other criteria
14 } at D_ALICE
As the above code is deployed, device
D_ALICE
must decide whether it is safe to
execute the thread or not. Clearly, the decision must be taken quickly so as to
not disrupt the purpose of the application. Ultimately, it is based on an analysis
of the code, giving special attention to the points where declassifications occur.
This paper addresses the technical problem of how to build suitable enforce-
ment mechanisms that enable domains to check incoming code against their own
allowed flow policies. Previous work [6] introduces, as a proof-of-concept, a run-
time migration control mechanism for enforcing confinement that lacks precision
