Re: fork, trivial confinement, constructor

[Bas Wijnen]

On Wed, Jun 14, 2006 at 12:59:50PM +0200, Marcus Brinkmann wrote:
> > The question of how to permit convenient debugging, without
> > accidentally introducing security vulnerabilities is (as far as I am
> > aware) a rather under-explored problem space.  Many designs are
> > possible; the one I'm about to propose is just a suggestion to start
> > discussion.
> > 
> > It seems to me that a reasonable policy would be that a program should
> > be able to get a debug capability to a "victim" program if:
> > -The program can provide capabilities to the space bank and CPU
> > schedule from which the victim is running.
> >    AND
> > -The program can provide copies of all the capabilities that were
> > packaged into the victim's constructor by the meta-constructor.
> 
> Well, you are assuming that a requestor should only be allowed to
> inspect programs with the permission of the creator.

No, I don't think he does.  What he seems to suggest is extra system code (in
the space bank, probably), which automatically allows transparency when these
conditions are met.  This means that the creator doen not need to give this
permission explicitly, it will work automatically.

However, the creator can of course veto the debuggability by inserting a
capability to a private object (that the program doesn't actually use at all),
for example a copy of the parent's scheduling capability (with the limit set
to 0).  The instantiator will not be able to present this capability, so
debugging will be disallowed by the space bank.

> My position is that a user should be allowed to inspect programs with the
> permission of the law.

This can be interpreted in two ways: at least, or at most.  IMO the user
should have at least all the rights that the law gives.  Because the law is so
complex, it is likely that this means that in some cases unlawful things may
be possible.  However, it guarantees that in no case a technical restriction
can be used to "disable" the law.  (This is not always true.  There are some
parts of the law really should be "enforced" through social means, by making
the system administrator or machine owner do things.  But at least for most of
the law, I think this is ok.)

> (In fact, I am already compromising, by providing privacy, ie isolation
> between child processes.  Law does not provide absolute privacy, but the
> amount of privacy law provides is quite strong and comes pretty close to
> absolute isolation, much closer anyway than to absolute control over how
> bits are copied).

I don't see the compromise.  The isolation of child processes is not about
privacy of people, but privacy of processes.  Those processes don't have
rights, and they have no protection against the user owning them.

> I think it was Pierre who suggested a feature where one can detect if
> a page was written to by somebody else.  This may be an idea worth
> pursueing: Instead of restricting access, one could increase
> transparency and monitoring.

Indeed this is an interesting way to solve security problems in some cases.
It's like fire alarms or emergency breaks: You can use them if you need to,
but you have to break a seal.  If you use them when you aren't allowed to, you
are punished through social means (lawsuits, fines, losing friends, etc).  Of
course this isn't applicable in many cases, in particular when there isn't
much social contact between the involved users, but it can work in some cases.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature