Re: Potential use case for opaque space bank: domain factored network stack
"Jonathan S. Shapiro" <[email protected]>
| Newsgroups | gmane.os.hurd.l4 |
|---|---|
| Organization | The EROS Group, LLC |
| Message-ID | <[email protected]> |
On Mon, 2007-01-08 at 06:05 +0100, Pierre THIERRY wrote: > Scribit Jonathan S. Shapiro dies 07/01/2007 hora 23:45: > > I, as a developer am free to say "I do not choose to let you inspect > > my programs, but you are free not to run them at all." > > I don't understand this part: how can the developer enforce this? Isn't > the machine owner the only one able to enforce this policy? Only in the sense that the machine owner can elect not to install EROS. Once EROS is installed on a TPM-enabled machine, it is possible to distribute programs in such a way that the user will *never* be able to inspect the bits in the clear. Difficult, but possible. The case I was referring to above is more local. I was trying to say that when the constructor builds a new program, the client normally gets an *entry* capability to that program, which does not permit debugging. The usual protocol is to ask for a debugging capability as a very early request. The service can, of course, refuse. Opaque installation and prevention of kernel substitution both require TPM. Without TPM you can substitute the kernel and/or learn the decryption keys that decrypt the distribution CD/DVD/whatever. shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100