Re: [Plash] Re: Zero-install and Plash

[Mark Seaborn]

Thomas Leonard <address@hidden> wrote:

> > I think the main practical reason for creating a minimal environment
> > (besides the general principle of least authority) is to be certain
> > that the behaviour of the programs you run is reproducible, so that
> > they are not accidentally depending on other files.  That's why people
> > use tools like pbuilder to set up chroot environments.
> 
> Sure, but with Zero Install you can get the same effect by clearing
> your environment. For example, I have the gtk+-2.0.pc file available
> in the directory:
> 
> ~/.cache/0install.net/implementations/sha1=1ea02e0ff9ee9eae327d64803846b38904ab9a23/lib

We could make the "implementations" directory unlistable, which would
give a kind of weak capability system.


> > How are the build scripts sandboxed?
> 
> With plash, of course ;-)

Just checking :-) because I looked at the ROX source from SVN and
didn't find any references to pola-run/pola-shell (except for where
tar is invoked).


> > You could put the config settings directory there, but I think the
> > file that specifies the instantiation should go in a central location,
> > for two reasons.
> >
> > Firstly, it can be quite sensitive, in the sense that it would list
> > files to grant to the instantiated application.  So if we accidentally
> > granted it the right to modify that file, it could grant itself access
> > to anything by adding filenames to the list.
> 
> If the sandboxed app can modify its own launcher then we have a
> serious problem anyway: it can just stop it from using pola-run in the
> first place!

Good point.  This is also a reminder that until the file manager only
launches programs with limited authority, there is the risk that an
untrusted program will create files that tempt the user to run them.
There is a similar problem with symlinks.


> > Is it necessary to ask the user to confirm the public key associated
> > with each zero-install feed?
> >
> > Suppose feed A depends on feed B.  Couldn't feed A list the public key
> > used to sign feed B, so that the system can check that B's interface
> > comes from the source that A expected?
> 
> Yes, and we probably should. I'm not sure about liability, though - if
> someone I don't know creates a binary for ROX-Filer (PPC, etc) then I
> add a feed to it from the main interface. When running it, users of
> that platform are asked to confirm that they trust the person
> providing the feed. *I* don't necessarily trust that person, so I
> can't really tell the injector to automatically trust their key.

Yes, that's tricky.  You don't want to vouch for the binaries someone
else has built because you have no way of checking those binaries.
But someone else using them has no way of checking either, and they
have no basis on which to accept or refuse the public key, so doesn't
this just move the problem from the creator of the main feed to the
user of the architecture-specific feed?

What if you took your binary packages from Debian?  They have
ROX-Filer 2.4.1 built for a range of architectures.


> > Then we would be left with just one public key for the user to check
> > per application started with 0launch.  We could eliminate that too by
> > including the public key in the feed's URL -- although that assumes
> > that feed URLs are always received via a secure channel.
> 
> Then your dependencies break each time the signing key changes (new
> maintainer, etc).

You could create a separate key pair specifically for signing the
feed.  Then the first maintainer could pass this on to subsequent
maintainers.

Having per-feed keys would mean you wouldn't have to put the URL into
the feed's XML file (something which gets in the way of mirroring).

There is potentially a sort of confused deputy problem associated with
trusting maintainers' public keys, because it doesn't distinguish
between packages from the same maintainer.

This isn't a problem at the moment, because Zero-install runs all
programs with the user's full authority.  But suppose it didn't, and I
run SSH and FooEdit with different authority.  FooEdit's maintainer's
key would be trusted.  FooEdit's maintainer could use a DNS attack or
some other attack to replace SSH's XML feed file (fetched via HTTP)
with another file, which would then run with SSH's authority, allowing
FooEdit's maintainer to get my SSH private keys.

Cheers,
Mark