Re: Restricted storage

[Jonathan S. Shapiro]

On Mon, 2006-05-29 at 11:16 +0200, Bas Wijnen wrote:
> Hello everyone,
> 
> We've been discussing the options of restricted storage a bit.  These
> "restrictions" are from the supplier of the storage.  It is possible that
> there are different restrictions for different suppliers (that is, for the
> parent, and for the parent's parent, etc).  I'll say some things which I'm
> pretty sure about first:
> - There are two types of restricted storage: read-only, and no-access.  Both
>   types do not provide access to the capabilities of the running program.
> - When a user starts a sub-Hurd (or debugs a program in some other way), it
>   must be impossible for the program, or any of the programs it spawns on its
>   own storage, to become restricted.
> - If a user debugs a program (in a sub-Hurd or otherwise), the program must
>   not be able to detect this (except through contact with other programs which
>   can see it, but they are not likely to have capabilities to them).  A
>   program's behaviour must thus be completely orthogonal to the fact if it's
>   being debugged.
> 
> I think Jonathan does not agree with the last two points.  These are design
> choices, and he makes different choices.  That's fine.  I'm just saying that
> these are the choices I expect the Hurd to make.

Yes, but my reason on the last point may surprise you: I disagree about
the "undetectable debugging" point because it is, in principle,
impossible to achieve. I have no objection to the idea that debugging
should be as non-intrusive as possible. It is also okay if the program
has to go to extraordinary means to detect that it is actually being
debugged. However, I do not know of any way (technically) to prevent
detection by a program that is *willing* to go to extraordinary means.


shap