tion when the message is received. Thus, the application knows an
upper bound on the sender’s send label. In our file server example,
a process writing
u
’s file must supply
V
=
{
u
G
0
,
3
}
to prove it
speaks for
u
. The file server, in turn, verifies the process speaks for
u
by checking
V
(
u
G
)
≤
0
before accepting a write to
u
’s file.
An alternative design might eliminate
V
and just supply message
recipients with a copy of the sender’s send label—in effect, con-
veying all of a process’s credentials with every message it sends.
However, such designs lead to security problems in which an at-
tacker can trick a process into exercising unintended privileges, a
pitfall known as the
confused deputy
problem [12]. In our example,
a process that speaks for multiple users must explicitly name the
credentials it intends to exercise for each write.
Level 0 and mandatory integrity
The
0
level permits the con-
struction of mandatory integrity policies. For example, a process
P
with
P
S
(
u
G
) =
0
can speak for
u
, but since
0
is less than the de-
fault send level of
1
, it cannot further disseminate the privilege: the
minute
P
receives a message from a process
Q
that does not speak
for
u
(
Q
S
(
u
G
)
≥
1
),
P
S
will become tainted and
P
will lose its abil-
ity to speak for
u
. Thus,
P
cannot act for
Q
and relay low-integrity
data into
u
’s files.
As with secrecy, different defaults in send and receive labels al-
low targeted exclusion of particular processes. An example is pre-
venting system files from being corrupted from the network. The
file server can allocate a compartment,
s
, and require
V
(
s
)
≤
1
for
writes to system files. Setting the network daemon’s send label to
{
s
2
,
1
}
then ensures that no process contaminated with data from
the network can overwrite system files.
5.5
Capabilities and preventing contamination
The discretionary verification label can be used to implement many
application-defined security policies, but it is limited in one impor-
tant way: An application can choose to ignore a message after ex-
amining
V
, but since the message was already delivered (to allow
V
to be examined), the application’s labels have already been con-
taminated with the message’s taint. In general this taint cannot be
undone. Thus,
V
can flexibly verify integrity but cannot prevent in-
appropriate contamination. Imagine, for example, a mail reader that
starts an untrusted program to read an attachment. The mail reader
can, and should, accept contamination from other system processes,
such as the file system; but though it needs to communicate with the
attachment program, it doesn’t want to accept contamination from
it. A compromised attachment that develops a high taint should lose
the ability to send to the mail reader.
What is needed is a way to shift a simple form of message filter-
ing into the kernel. Asbestos supports this in a straightforward way
by integrating communication ports with the label system. The re-
sult not only prevents undesired contamination but also ends up
providing the semantics of capability-based send rights.
