A Dependently Typed Ambient Calculus

Abstract

The Ambient calculus is a successful model of distributed, mobile computation, and has been the vehicle of new ideas for resource access control.

Full text

Page 1

A Dependently Typed Ambient Calculus
C´ edric Lhoussaine and Vladimiro Sassone
University of Sussex, UK
Abstract
The Ambient calculus is a successful model of distributed, mobile computation, and has been the vehicle
of new ideas for resource access control. Mobility types have been used to enforce elementary access
control policies, expressed indirectly via classification of ambients in groups by means of ‘group types.’
The paper presents a theory of dependent types for the Ambient calculus which allows greater flexibility,
while keeping the complexity away from the programmer into the type system.
1Introduction
The calculus of Mobile Ambients [11] (MA) is a distributed calculus of mobile processes based on three
fundamental notions: locations as computational environments, (subjective) mobility of locations, and
local communication. Processes live inside ambients, and inside ambients compute and interact. Ambients
relocate themselves, carrying along all their contents: their migration, triggered by the processes they
enclose, models mobility of entire domains and active computational loci. Relevant variations of the basic
calculus include Safe Ambients [19], Boxed Ambients [4], and NBA [5]. The theory of MA has developed
in several directions, including behavioural semantics [21, 23], logics [13, 26, 18], and model checking [6,
14], while applications are flourishing: resource control [27, 2], semistructured data and query languages
[8, 7] and, lately, modelling of biological processes [25].
The work on types for ambients, initiated in [12], has introduced some interesting innovations. In
particular, it led to natural concepts of mobility types (cf., e.g. [9, 4, 22, 15]). The common framework
proposed so far in the literature for mobility control relies on groups and group types. Groups represent
collections of ambients with uniform access rights, and policies like ‘n CanMoveTo m’ are expressed by
saying, for instance, ‘n belongs to group G and all ambients of group G can move to m.’ These and similar
simple constraints, such as ‘m accepts ambients of group G,’ are then enforced statically by embodying
groups in types. This approach’s merit is to simplify considerably the type system. It allows to avoid the
difficulties of dependent types, since it replaces (variable) ambient names with (constant) group names.
The loss in expressiveness and flexibility, however, is self-evident.
This paper generalises the approaches to access control based on groups by using types explicitly de-
pendent on ambient names, so that policies like ‘n CanMoveTo m’ can be expressed directly. The task
involves issues of technical complexity, and we believe that our approach contributes significantly to ad-
vance the theory of type-based resource access control in the Ambient calculus. The guiding principle
behind our work is to allow for flexibility in control policies, while pushing the complexity to the type
system. We elaborate further on this below.
Dependent types vs groups
At the formal level, dependent types are indeed trickier to work with than groups, as already suggested
in [9]. However, they are very expressive and ultimately, at the programming level, not necessarily more
difficultto use than groups. It may indeedbe challenging,if not impossible, to partitionambientnames into
groups in order to implement the desired security policy in complex applications. By referring directly to
names, instead, a programmer avoids a level of indirection, and is less prone to policy specification errors.
The type systems we propose here aim at harnessing the complexity of dependent types and relegating it
to inner working of the type system, so as to keep the burden off the programmer, and consequently make
programs more robust.
1

Page 2

To illustrate the point, let us consider a naive and specialised taxi server whose intention is to provide a
taxi service usable only by ambient n:
TaxiServ(n) =!(νtaxi: A)(taxi[] | n[intaxi]).
The process creates a new ambient called taxi, with some type A, together with an ambient n which can
move to it. Due to the scoping rules, an external ambient m[P] can only move into the taxi by first moving
to n and then escaping it after being transported to taxi. For instance, for P = inn.outn.P?, the system may
evolve as follows.
m[inn.outn.P?] | TaxiServ(n) →∗taxi[m[P?] | n[]] | TaxiServ(n).
To avoid this, A must restrict the children allowed of taxi to, say, only ambient n. Using groups – for
instance in the setting of [22], where an ambient type a : amb[G,mob[G]] assigns group G to a and
specifiesthatGistheset ofgroupsofthoseambientswhichais allowedtomoveto–topreventanyambient
other than n to occupy the taxi, n must be the only ambient with a type of the form amb[H,mob[{G}∪H]],
where G is the group of taxi. Such condition is clearly beyond the control TaxiServ(n) application, as the
environment may create new names with types that violate it. Making G private is not a solution, as it
forces n to be private too, so defeating its very purpose. Indeed, in a term such as (νG)(νn: A)P | Q,
where G occurs in A, n can not be communicated to Q (not even via subtyping [22]).
With dependenttypes we would simply and directly mention n as a possible (or perhaps the only) child
for taxi. This leads to ambient types of the form amb[mob[P,C]], where P is the set of names of those
ambients allowed to contain taxi and, dually, C is the set of names of those ambients allowed to reside
within taxi. Type A above can be simply amb[mob[{top},{n}]], where name top represents the top-level
ambient. Yet, the taxi ambient would be guaranteed to have n and only n as a possible child, with no
need for n to be private. Of course, such simplicity in expressing types comes at the cost of additional
complexityat the type system level. Primarily, we need to enforceconsistency between the type of a parent
ambient and those of its children. To exemplify, when a taxi is created, n receives a new capability to have
taxi as its parent; the type of n – which actually predates the creation of the fresh instance of taxi – must
then be updated accordingly. Observe that in a conventionaltype system, the effect of the new name would
be confined inside the scope of its definition, and would certainly not affect the type of n. In our case,
however, leaving n’s type unchanged leads to an unsound system (cf. Example 1).
In order for n to be aware of any additional capability it may acquire over time, we introduce the
pivotal notion of abstract names. Such names are used only in the derivation of typing judgements, to
record potential name creations, either by a process or by its environment. As it will be clear later, abstract
names intuitively play the role of group names in their ability to cross the scope of name restrictions.
Flexibility
The main contribution on this paper is the use of dynamic types to increase expressiveness, which can be
fleshed out as the ability to deploy security policies at run time. More precisely, we want servers flexible
enough to provide services specialised to each particular client, so leading towards secure, highly modular
programming. In other words, a service specifically provided for client c1must be unusable by client c2.
Such objectives may be achieved in several different ways, as for instance by adding special operators to
the calculus. In this paper we stick to the basic primitives of the Ambient calculus and investigate the issue
of personalised services at the level of types.
The taxi server discussed above is not particularly interesting, essentially because it is not a server at
all: it does not interact with any client, but provides again and again the same ‘secure’ service to the same
specific client. To illustrate our ideas, let us first explore a generic, or dynamic, version of the taxi server,
GTaxiServ, using groups. A most natural protocol seems to require the ability to communicate both group
and ambient names, as below.
GTaxiServ =!(x)(y)(νtaxi: amb[x,mob[G]])(taxi[] | y[intaxi])
The protocol consists of two exchanges: a client n with type amb[H,mob[H ]] sends a group name G
which belongs to H and its name n; the server creates a taxi specialised for n. Some security issues
2

Page 3

arise. Firstly, G should be a fresh (i.e. restricted) group name, and again this forces to restrict n as well.
Secondly, by communicating group names we expose ourselves to the risk of unintentionally disclosing G
to malicious eavesdroppers. We definitely need to devise more sophisticated protocols. In any case, a brief
reflection on the guarantees that a satisfactory type system is expected to make, shows the need to track
information about the group names GTaxiServ may receive. That is, communications have to be typed as
well as movements. It thenfollowsthat DTaxiServ can notbe writtenas above: communicatinga groupand
an ambient name to the same ambient is impossible, since only one topic of conversation is allowed inside
an ambient [9]. Finally, group types would have the form gr[G], for G a set of groups (which incidentally
is similar to the approach of [15]). But then, we would be essentially using (group) dependent types...
The type system we propose for dynamic types is a natural extension of the one we illustrated above,
which only deals with mobility. Namely, we simply require that communications of ambient names and
variables be reflected in the types. For instance, the dynamic taxi server will have the form:
!(x)TaxiServ(x) =!(x)(νtaxi: amb[mob[{top},{x}]])(taxi[] | x[intaxi]).
Communication increases the complexity of the type system, because the rules need to track information
about receivers, too. It makes little sense to type communication via the usual exchange types, because
receiving different names may lead to orthogonal behavioural and mobility properties. Subtyping does
not help towards a unifying treatment (cf. Example 2). We approach the problem by tracking the names
that may be received at a given variable. This enriches ambient types which, in addition to a mobility
component, acquire a communication one. A typing assignment n: amb[mob[P,C],com[E,L]], where
E and L are sets of ambient names, means that n may be communicated inside any ambient in E, and
dually, that any ambient in L may be communicated within n. It is important to remark that even if such
components only carry finite sets, the volume of informationexchanged is in general not bounded. Indeed,
the joint effect of name creation and the use of abstract names, allows to distribute new communication
capabilities at run time, and communicate infinitely many names.
Plan. The paper proceeds as follows. Section 2 presents a simple type system with dependent types. We
focus on mobility, that is the Ambient calculus with no communication at all. Then, in Section 3, we
investigate dynamic types allowing communication of ambient names. For the sake of simplicity, we do
not address the issue of communication of capabilities, even though this can easily be integrated following
our approachto a dependentlytyped ambients. The appendicescontain complementarymaterial which can
safely skipped. Sections A and B lists syntax and semantics of the Mobile Ambients; Section C give the
full typing proof of the (dynamic) taxi servers of Sections 2 and 3; Section D sketches the main proofs.
2A Simple Dependent Type System
In the paper we use the standard Ambient calculus with asynchronous, monadic communication. (We
remark that our results do not depend on such choice.) For the reader’s convenience, syntax and reduction
semantics are reported in the Appendix. In this section we consider the pure Ambient calculus, that is the
calculus restricted to the mobility features. Communication will be studied in Section 3.
2.1 Types and definitions
The syntax of types is given in Figure 1 where N denotes an infinite set of abstract ambient names and the
symbol ? stands for the self-ambient, whose meaning is explained below. The type cap[P] denotes the
type of a capability which can be exercised within any ambient whose name occurs in P. An ambient type
has, for the moment, just one component: a mobility type. Ambient n with mobility type mob[P,C] is
allowed to be a sub-ambientof all ambients whose name occurs in P; i.e. P is the set of possible parents of
n. Moreover,an ambient is allowed to occur as sub-ambient of n if its name occurs in C, the set of possible
children of n. We define some useful notations on types:
amb[M]mob= M
mob[P,C]↑= P
mob[P,C]↓= C
3

Page 4

Ambient (concrete) names
n,m,... ∈ N
K
::=
Abstract names
n,m,... ∈ N
M,N
Capability types
cap[P]
amb[M]
Mobility types ::=
mob[P,C]
Ambient types
A
::=
where P,C ⊆ N ∪ N ∪ {?}
Figure 1: Types
We use two kinds of typing contexts: abstract contexts (ranged over by Ξ,Θ,...) and concrete contexts
(ranged over by Γ,∆,...), which map respectively abstract and concrete names to ambient types. We use Π
to denote either an abstract or a concrete context. We note by (Π,Π?) the union of disjoint contexts of the
same kind. According to the informal meaning of types, type assignments in concrete typing contexts are
related to each other. Consider for instance
Γ = n: amb[mob[P,C]], m: amb[mob[∅,{n}]],
where the type of m allows it to have n as a child. Coherently, the type of n should allow n to have m as a
parent, i.e. m ∈ P. This can be expressed by the central notion of context update Γ(n:A), which updates Γ
with respect to a fresh type assignment n : A:
(Γ,∆)(n:A)= Γ(n:A),∆(n:A)
(m: amb[M0])(n:amb[N])= m: amb[M1],
where
M↑
1=

M↑
M↑
0∪ {n}
0
if m ∈ N↓
otherwise
and
M↓
1=

M↓
M↓
0∪ {n}
0
if m ∈ N↑
Context updateis pivotal in our typesystems to expressthe typing of namecreation. We defineunion(resp.
inclusion and equality) of types as component-wise set union (resp. inclusion and equality); the notation
nm(A) (resp. an(A)) stands for the set of (abstract) names occurring in A. It is extended to all types and
typing contexts.
2.2 The type system
Our type system deals with typing judgements for values and processes, that is
Γ ?ΘV : T
and
Γ ?Ξ;Θ
a
P,
where T is either an ambient or a capability type. The first judgement reads as “V has type T with respect
to the concrete context Γ and the abstract context Θ.” In the second one, ambient name a stands for the
ambient where P is running, which we call the current location of P. In other words, P is guaranteed to be
well-typed if run in a. Abstract contexts Ξ and Θ are used to account for potential name creations: those
arising from P are registered in the local abstract context Ξ, those performed by the environmentappear in
the external abstract context Θ. The role of such contexts is to “internalise” (a dynamic notion of) group
names, which move from being part of the language to being a inner mechanism of the type system.
Example 1. Let
TaxiServ(n) =!(νtaxi: A)(taxi[] | n[intaxi]),
Let Q = n[inn | m[outn.outn]]. We study the system P = TaxiServ(n) | Q, which we assume running in
some ambient named top. The server TaxiServ(n) creates an ambient taxi whose type allows it to accept
only n as a child. The scope (or “visibility”) of taxi is (taxi[] | n[intaxi]). We assume that Q is an ambient
n which may move in an ambient of the same name n and contains a child ambient m, willing to escape
for
A = amb[mob[{top},{n}]].
4

Page 5

A ∈ Types(Γ,Θ,a)
Γ ?Θa: A
(VA)
Γ ?ΘU : K,V : K
Γ ?ΘU.V : K
(VP)
Γ ?Θa: A,ai: Ai
Amob⊆ Amob
i
↑∀i ∈ {1,...,n}
(VO)
Γ ?Θouta: cap[{a1,...,an}]
Amob⊆ Amob
Γ ?Θopena: cap[{a1,...,an}]
(N)
Γ ?∅;Θ
Γ(n:A),n: A{n/?} ?Ξ{n/n};Θ
Γ ?n:A,Ξ;Θ
Γ ?Θa: A
Γ ?Θina: cap[P]
Γ ?Ξ;Θ
P ⊆ Amob↓
(VI)
Γ ?Θa: A,ai: Ai
i
∀i ∈ {1,...,n}
(VO)
a
P
Γ ?Ξ,Θa: A
Γ ?Ξ;Θ
P
b ∈ Amob↑
(A)
b
a[P]
a
0
Γ ?Ξ;Θ
a
P
Γ ?Θ,ΞV : cap[a]
Γ ?Ξ;Θ
Γ ?Ξ;Θ,Ξσ
Γ ?Ξ;Θ
(P)
a
V.P
Γ ?Ξ1;Ξ2,Θ
a
Γ ?Ξ2;Ξ1,Θ
P | Q
a
Q
(P)
Γ ?Ξ1,Ξ2;Θ
a
a
P
(R)
a
(νn: A)P
a
P
(R)
a
!P
Figure 2: Simple Type System
twice out n. Thus, m must be allowed to run at the same level of n, and a type system should ensure that
any possible parent for n is also a possible one for m. This leads, for instance, to the following assignment.

In (taxi[] | n[intaxi]), ambient n gains access to taxi by means of name creation, viz. taxi, and the type
assignment must evolve to ∆ below (which actually is of the form Γ(taxi:A),taxi: A).

However, running P may obviously lead to ambient m becoming a child of taxi, thus violating the specifi-
cation expressed by the type of taxi. Indeed, we have
Γ =
top: amb[mob[∅,{n,m}]],
n: amb[mob[{top,n},{n,m}]],
m: amb[mob[{top,n},∅]].
∆ =
top: amb[mob[∅,{n,m,taxi}]],
n: amb[mob[{top,n,taxi},{n,m}]],
m: amb[mob[{top,n},∅]],
taxi: amb[mob[{top},{n}]].
P → TaxiServ(n) | (νtaxi: A)(taxi[] | n[intaxi]) | Q
????????????????????????????????????????????????????????????????????????????????
Therefore, P must be considered ill-typed. A naive approach would however try to typecheck (taxi[] |
n[intaxi]) (against ∆) and Q (against Γ) independently, and therefore accept P. Indeed, from Q’s point
of view, taxi does not exist (it is bound in TaxiServ(n)), and Q behaves well. From the viewpoint of
TaxiServ(n), although taxi exists, the specification given by its type is respected: ambient n is allowed to
move into taxi. Considering TaxiServ(n) and Q as stand-alone processes prevents from realising that their
interaction may lead to a breach of the intended access policy.
P?
and
P?≡ (νtaxi: A)(taxi[] | n[intaxi] | n[inn | m[outn.outn]]) →∗(νtaxi: A)(taxi?m[] | n[n[]]?).
?
Example 1 motivates the use of abstract contexts. They are a means to record the new capabilities
which may potentially arise from name creations performed in external processes. Since such names are
bound, they cannot be referred to by name in typing contexts: we use abstract names to represent them.
The typechecking of process Q in Example 1 must then be carried out with an external abstract context
Θ = taxi: A, representing the potential creation of a name of type A, and an empty local abstract context,
as Q does not create names. In other words, we are led to prove Γ ?∅;Θ
a more informative type for n, viz. its global type amb[mob[{top,n,taxi},{n,m}]], which states that n is
allowedto runwithin top, n andsome ambienttaxi, to be createdbyits environmentandwhose actualname
we do not known yet. (We stress that the name taxi is just a placeholder; the information that leads to the
global type is carried by A.) Since m does not appear in Θ, its global type remains amb[mob[{top,n},∅]],
and we can conclude that Q is ill-typed. Indeed, there exists a possible parent of n which is not a possible
one for m, namely taxi.
topQ. From Γ and Θ, we can deduce
5