Re: fork, trivial confinement, constructor

[Marcus Brinkmann]

At Wed, 14 Jun 2006 16:40:05 +0200,
Bas Wijnen <address@hidden> wrote:
> 
> 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.

You are right, my wording was not careful enough.  I meant precisely
this "veto mechanism".  So, a more careful wording would be that Eric
is assuming that the requestor should be allowed to prevent inspection
of the programs.  The net effect is about the same.  In fact, the two
conditions above can be read as: "The program can (at least in
principle) provide copies of all capabilities that the victim has."
But this just means that the program could have instantiated the
victim in the first place, and the constructor serves no relevant
purpose.

> > 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.

Or precisely :) In reality, it doesn't matter, because the law is not
precise.  I certainly did not mean "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.)

I think I agree.

> > (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.

Well, yes, but the same is true for confinement.  One has to make the
obvious transfer from the programs to the users.  If you have a shared
machine, there are multiple users.  For example, a sysadmin is not
allowed to read your emails, even if he can.  Privacy law protects
your right to secret communication.  OTOH, that law is not absolute:
Law enforcement can get permission by a court to spy on your
communication, with the help of the sysadmin.  In fact, in Germany,
telecommuniation companies are required to provide spying facilities
to the government agencies (regulation "G10").

One could turn my argument against me and ask: "With which
justification do we provide tools for "absolute" privacy if society
denies the right to "absolute" privacy?  I think that there is some
merit to such an argument, but that it is also much weaker than the
argument I am making in the realms of contract: Privacy rights are in
practice much stronger and better established than a right to enter
arbitrary contracts that has been discussed.

> > 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.

Yeah, although it also provides an opportunity and incentive to
establish social contacts, thereby strenghtening the network.  I think
a related issue is P2P research, where resilience against hostile
intruders is achieved probabilistically without disabling their
participation completely.  In many ways I think that these
technologies model much better the way society and contracts work in
the real world, but I have not yet thoroughly explored this subject
matter.

Thanks,
Marcus