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@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@mail.eros-os.org>, Capability Talk <cap-talk@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.: http://www.webstart.com/jed/papers/Components/ ) 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@mail.eros-os.org http://www.eros-os.org/mailman/listinfo/cap-talk