[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 1.5.0.9 (X11/20061231) |
-----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-----
- Re: Translucent storage: design, pros, and cons, (continued)
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons,
Tom Bachmann <=
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/12
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/14
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- constructor daemon vs. constructor library, Neal H. Walfield, 2007/01/15
- Re: constructor daemon vs. constructor library, Jonathan S. Shapiro, 2007/01/15