Fwd: [cap-talk] Re: [e-lang] Introducing Emily, "...capabilities are useless too..."

coderman coderman at gmail.com
Mon Feb 27 13:13:38 PST 2006

forwarding an interesting discussion on the nature of a "secure
domain" where key based capabilities can be utilized securely.

When you get mired into threat models involving well fundend
adversaries using exotic interdiscplinary vulnerability assesment and
exploitation the definition of "secure domain" becomes extremely
verbose and difficult (some would argue effectively impossible for
anyone but large TLA's) given the amount of context required to state
security in the exotic threat model with sufficient trust and defense
in depth.

[exotic threat models == tempest, global active adversary, DoS/attacks
expending significant network and real world resources (very wide
spectrum attacks at high power), domain specific physical access side
channel attacks, etc, etc, etc in an ongoing cycle since we all know
these parameters change over time]

---------- Forwarded message ----------
From: Jed at Webstart <donnelley1 at webstart.com>
Date: Feb 27, 2006 11:51 AM
Subject: [cap-talk] Re: [e-lang] Introducing Emily, "...capabilities
are useless too..."
To: Discussion of E and other capability languages
<e-lang at mail.eros-os.org>, Capability Talk <cap-talk at mail.eros-os.org>

My main point is #3 below.  Please skip down to that if reading time
is limited.

At 01:53 PM 2/23/2006, Constantine Plotnikov wrote:
>David Wagner wrote:
>>Constantine Plotnikov writes:
>>>This is a good analogy. If you close one door, you have one less
>>>door to watch out during program design.
>>But now I come back to the distinction I was trying to draw between
>>unintentional leakage of secrets vs deliberate leakage of secrets.
>>I agree that there is value in looking for programming language mechanisms
>>that reduce the likelihood of unintentional leakage of secrets.  But what
>>I'm arguing is that there's no point trying to forbid malicious code from
>>deliberately leaking secrets.  Given the existence of covert channels, you
>>probably can't prevent it anyway.  "Don't forbid what you can't prevent."

#1.  While I agree with the difficulties in preventing covert
communication, I don't more generally agree with "Don't forbid what
you can't prevent", at least in this instance.  If confinement is a
natural effect of tokenized permission transfers (e.g. via
capabilities) where capabilities to objects are bundled with the
permission to communicate to the server of whatever object the
capability grants access to, then it seems quite natural and
effective to include that permission to communicate along with the
permission to access the object.  It may well be that communication
is possible in any case (e.g. via a covert channel), but by bundling
it explicitly with a permission to access an object it makes other
communication outside that explicitly granted only possible by
extraordinary means such as covert channels - which are available in
any case.  In my opinion it's preferable to explicitly limit such
communication rather than simply give up in the face of covert
channels and open all communication.

I admit that I do find it amusing finding myself on this side of this
argument in that the network operating system that I designed and
implemented through much of the 1980s (NLTSS, e.g.:


) took the opposite position on this issue - arguing that the
'natural' condition of processes is to be able to freely communicate
on a general network and that only object access (not the
right/permission to communicate) should be limited by capability
transfers.  At some point I came to accept that I was wrong in taking
that approach, I think mostly as a result of dealing with so many
situations where limiting communication (e.g. with firewalls) can
indeed be useful, even accepting the potential presence of covert
channels.  I generally feel that covert channels are more of a
theoretical than a practical threat, except in cases of dealing with
quite sensitive information like classified information or sensitive
intellectual property or business information.

>There are ways to prevent covert channels in some situations for
>some tasks. Examples of mechanisms that can be used to construct a
>solution for specific task are:
>- scheduled message exchange
>- limiting amount of messages
>- denying access to timer
>- mutually exclusive execution
>- isolation (process that is run on separate computer cannot use
>memory timing to leak data)
>- replay
>If task is not solvable in general, it does not means that it cannot
>be solved in some particular case. And if we are solving the problem
>in particular case, it is better have some foundation problems like
>capability confinement and exception data leaks solved.

#2.  I won't explicitly address the above means to prevent covert
channels except to say that given the history of analysis of covert
channels I'm somewhat skeptical of such efforts.

One thing I think it's important to keep clear is that the mechanisms
that have generally been discussed for covert channels require
cooperation on both ends of the channel.  No mechanisms that I'm
aware of have been demonstrated which 'force' communication from one
process into another unwilling recipient (e.g. to access an object
without explicit permission).

#3.  My main reason for writing is to dispute this statement:

>Also if we extend your argument, capabilities are useless too,
>because capabilites do no limit authority exchange use in presense
>of covert channels. If we have bidirectional covert channel, we can
>just forward requests to capabilites on other end by proxying.

I hope in the above you are meaning that capabilities are useless too
<in preventing communication through covert channels> vs. being
useless in general.  Of course the primary use for capabilities is in
explicitly transferring permissions between processes (subjects,
active objects, domains, whatever you choose to call active computing
entities).  One such permission is the permission to communicate
which, in the strongest capability systems, always explicitly
accompanies any transferred capability.  That is, when a capability
is transmitted from one process to another the permissions of the
capability include the authority to communicate to whatever service
provides the explicit permissions granted by the capability.  For
example, a capability to a file includes permission to communicate to
the appropriate file server.  However, most permissions explicitly
transferred by capabilities are some form of object access beyond the
authority to communicate to the object server.

While it's true that in the face of covert channels the value of
transferring a permission to communicate via a capability (e.g. as
above the permission to communicate to a file server) may be somewhat
constrained (the process and the file server may be able to
communicate in any case via a covert channel), the primary value of
the capability in transferring permissions (in the example the
permission to access a file, which is not compromised by the presence
of covert channels) is still present.

Providing confinement in the face of covert channels is indeed a
difficult problem.  However, I think it's important not to suggest
that capability tokenized transfers of permissions have no value
simply because one permission, the permission to communicate, is
difficult to control (with or without capabilities).  Most
permissions are not so difficult to control and can be perfectly
adequately managed with capabilities.  I'm not alone in arguing that
tokenizing permissions via capabilities provides many advantages over
conveying permissions by other means such as access lists or ambient
authority mechanisms (e.g. users/groups and permission
bits/configurations for users/groups).  These values of capability
transfers are not rendered useless simply because covert channels
limit the ability of capabilities to also manage the permission to communicate.

You (Constantine Plotnikov) may be arguing that a capability
infrastructure can't prevent a process from communicating permissions
via covert channels (e.g. by proxy).  This is true just as one can't
prevent data from being communicated via covert channels.  However,
this is again only dealing with the potential confinement value in
capabilities as distinct from what I see as their primary value in
providing for transfer of permissions for object access.  Covert
channels can thwart efforts at confinement, but they cannot thwart
efforts to limit object access to those processes which have been
explicitly granted access - even if via a covert channel through a proxy means.

--Jed http://www.webstart.com/jed/

cap-talk mailing list
cap-talk at mail.eros-os.org

More information about the cypherpunks-legacy mailing list