On 27/10/05, Jonathan S. Shapiro <[EMAIL PROTECTED]> wrote: > On Thu, 2005-10-27 at 02:00 +0100, Brian Brunswick wrote: > > > > So is this confinement in some sense relative to assumptions about > > additional access? The program could then give the subsystem > > additional capabilities and change that? But nothing else can because > > it hasn't the capabilities to the new subsystem? (/Can/ capabilties be > > sent over IPC channels in EROS, or only at creation time?) > > I am not entirely sure that I understand the question, but let me > attempt an answer and we will see how close we get. > > The test performed by the constructor establishes an initial condition. > It guarantees that the initial capabilities held by the new process > divide exactly into two sets: > > 1. Capabilities that are transitively read-only. These are harmless.
Ah yes... I meant relative to this definition of "read-only" capabilities. Does the system somehow enforce that the implementation of a read-only capability can't save any data, or isn't that immediately a big channel where data can leak. > Yes, capabilities can be transmitted via IPC. However, an endpoint > capability is NOT considered to be transitively read only [exception: a Ah, thats another question I was going to ask. Can you clarify the meaning of "endpoint capability" please? > This is a surprisingly effective barrier, because it makes natural human > laziness an ally rather than a source of vulnerability. In consequence, > it tends to lead to systems that default to safe configurations rather > than unsafe configurations. Absolutely!! > Can you explain where you think the escalation is happening? The > constructor does not have special privilege because of any escalation. > All of its privilege derives directly from the capabilities that it > holds. The constructor does not have any special privilege beyond what > it's capabilities permit. But its constructing something that has those special capabilities, on the demand of a client that doens't. So the client is getting some sort of service done for it with escalated priviledge... Exactly what setuid does. (only more secure we hope) > > Secrets are not directly relevant to confinement. Confinement is a > constraint on outward communication. > > Yes, if you are concerned about covert channels, then you get into > real-time issues, and scheduling of multiplexing, and a long list of > other challenges. These do not have general solutions, which is very > troubling. There *is* some good news: > > 1. The sources of covert channels can be reduced without altering > the program. How are "read-only" capability restrictions enforced for this? > > 2. Capabilities cannot be leaked over covert channels. They can be > proxied, but once the program that holds the capability is killed > you know that the access is terminated. Yes, that has to be a big benefit. So read-only may just apply to capability transfer. Indeed, perhaps thats enough... > > 3. Covert channels do not allow theft of information. They only allow > *disclosure* of information. English: we don't need to solve the > covert channel problem in order to solve the virus and hostile > plugin problem. Hmm.... not sure this is a useful distinction in the presence of buffer overflows and other similar bugs. Disclosure may be prompted too easily.... > > Because of covert channels, confinement of *data* is not absolutely > possible. Confinement of authority (capabilities) *is* possible. This is > why I feel that the primary advantage of confinement as the standard > tool for process instantiation is its effect on system structure and > developer habits. Ah ok. So confinement is confinement of capabilites. Which in a persistent system is really, really important. (And not much less in a non-p system) -- [EMAIL PROTECTED] _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
