[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Translucent storage: design, pros, and cons

From: Tom Bachmann
Subject: Re: Translucent storage: design, pros, and cons
Date: Fri, 12 Jan 2007 19:58:34 +0100
User-agent: Thunderbird (X11/20061231)

Hash: SHA1

Jonathan S. Shapiro schrieb:
> On Fri, 2007-01-12 at 15:41 +0100, Tom Bachmann wrote:
>> Hash: SHA1
>> Jonathan S. Shapiro schrieb:
>>> Translucent storage does not undermine confinement at all, so your
>>> supposition is mistaken.
>> But there is no constructor needed to confine a program.
> Why do you believe this?

Well. I have the binary of a program (or, actually, it's source code,
but there exists a compiled version, for convenience). I load it into
memory and give it whatever capabilities I think are needed, enforcing
whatever properties I want. What can the constructor do that I can't?

>> As I understand it, the constructor serves as a trusted "mediator", that
>> allows to check the confinedness without constructing the process (in
>> non-translucent designs), that is, to run a program that is untrusted
>> without risking leakage, and without inspecting it.
> In EROS/Coyotos, this is true. Actually, it is a certifier, not a
> mediator (the constructor does not remain in the loop after creation).
> However: you ignored the other thing I said. Simply having a common
> place to encapsulate these algorithms is a sufficient reason to have a
> constructor.

Yes. I completely agree to this (although, then, the constructor is not
a directly relevant part of the design anymore wrt it's security
properties, but merely a outcome of applying the "principle of
separation" [I can't remember if it has been given a special name]).
- --
- -ness-
Version: GnuPG v1.4.6 (GNU/Linux)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]