Re: Translucent storage: design, pros, and cons

[Tom Bachmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan S. Shapiro schrieb:
> On Fri, 2007-01-12 at 15:41 +0100, Tom Bachmann wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFp9pavD/ijq9JWhsRAngOAJ0f4nxm+BgcUpY9DbrpETpJu4S7EwCfaiEK
XcCl9s976oHCfgDciUkOhOU=
=m92w
-----END PGP SIGNATURE-----