[Plash] Re: Zero-install and Plash

[Thomas Leonard]

On 7/18/06, Mark Seaborn <address@hidden> wrote:
> Hi,
>
> Should we continue this discussion on a mailing list?  Is it okay with
> you if I forward these mails to the plash list (and maybe
> zero-install-devel too)?

Sure, I'll reply to the mailing lists.

[ This is about using Plash and Zero Install together, so that you can
install and run programs in a restricted environment, even if there
are complex dependencies to resolve and the downloaded code must be
shared between programs and users in other security domains. ]

> "Thomas Leonard" <address@hidden> wrote:
>
> > On 7/17/06, Mark Seaborn <address@hidden> wrote:
> > > My thinking is that 0launch could download the files and then start
> > > the program using either pola-run or the Python Plash bindings.  It
> > > would build an environment consisting of the files in the zero-install
> > > package and its dependencies.  This way only the minimum required
> > > installation files would be present in the program's namespace.
> >
> > It's a bit tricky. For example, ROX-Session depends on ROX-Defaults,
> > causing XDG_CONFIG_DIRS to include a directory in the cache with
> > sensible defaults. Other applications inherit this environment.
>
> I guess the default file associations would need to be set up a
> different way?  e.g. Have a way of instantiating a bunch of
> applications at once.  This would only be an issue when installing ROX
> on an existing desktop; a newly-installed desktop could instantiate
> the defaults when you create a user account.

You want to link to the defaults rather than copy them. E.g., if I add
additional associations to ROX-Defaults (say, that clicking on an svg
file will download and run Inkscape) then users should get that
association on their next update.

> > Also, the cache is read-only, public (and probably shared over p2p at
> > some point), and contains impossible-to-guess directory names
> > (preventing accidents), so there's very little to gain by restricting
> > access to it.
>
> By public, do you mean you can set file permissions so other users on
> the same machine can use your cache with zero-install?

When there is no system-level cache, other users would typically
copy-and-verify from your cache rather than using your copy directly,
because they can't be sure that your copy won't be changed later
(e.g., by a virus you get), but the expectation is that there is
nothing secret or sensitive in the cache.

> 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

However, unless I have $PKG_CONFIG_PATH referring to this directory, I
can be pretty sure that no program will accidentally use this file. On
the other hand, a typical Debian system would have it in
'/usr/lib/pkgconfig' which could easily be included by accident,
requiring the use of pbuilder to prevent this.

> Is there any reason not to create a minimal environment?

No, it just seems moderately difficult to do and less useful than
other issues (like restricting write access to ~).

> > > In the ideal case I am assuming that there would be no need for a
> > > default environment, so it wouldn't grant access to /usr, /lib and so
> > > on by default.  Are there any zero-install packages that provide all
> > > their own environment, including libgtk, xlib, etc., through their
> > > dependencies?
> >
> > No, but we may start listing them at some point. That would allow the
> > injector to select an older version of a program if a required native
> > library was missing, and to choose between a native library and a zero
> > install one (people keep complaining about having to download
> > libraries they already have).
>
> Would you have to introduce another kind of declaration into the
> zero-install feeds to specify that, say, the file "/usr/lib/libX11.so.6"
> is good enough to satisfy the dependency, or the Debian package
> "libx11-6" is good enough?

Yes, something like that (not sure which).

> > > Are there zero-install packages
> > > that invoke 0launch themselves?
> >
> > Some of them. Build scripts (e.g. rox-release) are normally sandboxed,
> > and tend to run 0publish and gtk-2.4, for example. At some point, all
> > the build tools are likely to be run this way (gcc, scons, ...).
>
> How are the build scripts sandboxed?

With plash, of course ;-) It's done manually at the moment, but I want
to create a 0compile command to build binary packages from sources
with:

- Read access to all build dependencies (from the source interface)
- Write access to $TMPDIR (empty, deleted after the build)
- Write access to $BUILDDIR (to speed up rebuilds)
- Write access to $DESTDIR (the final binary package and interface)

So, 0compile will use plash to set up this restricted environment and
then run the package's build script in it. This wil run gtk-2.4 and
0publish through Zero Install, and therefore needs to be able to add
these to the cache.

> > > 2. The application is granted access to a freshly-created directory in
> > > which it can store configuration settings.  Having an instantiation
> > > step means you can create multiple instances of an app with different
> > > settings (and pet names) if you so desire.
> >
> > OK, here's an idea. AddApp already creates a ROX application directory
> > for the launcher - how about storing the configuration settings in
> > there?
> >
> > - Multiple configurations happen naturally.
> >
> > - Deleting a 'launcher' deletes the configuration settings (no pile-up
> > of forgotten config files in hidden directories). Would require a bit
> > of user re-education.
>
> 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!

> Secondly, if the user is to be offered the facility to review what
> authority they have granted to instantiated applications and maybe
> revoke it, there needs to be a searchable list of what they have
> granted.

The searchable list would be the directory containing the launchers...

> The full answer to these problems is to have a persistent
> object/capability store.  In such a scheme, an application instance
> would be an object with references to objects it has been granted
> (such as its configuration directory).  The application would be able
> to store futher capabilities that it has been granted (e.g. via a
> powerbox or drag-and-drop) and retrieve them later, including after a
> reboot.  Similarly the user's Start menu (or similar) would contain
> references to applications' executable objects.

I don't quite understand how this helps. Why does an application that
has been allowed to write a file once get to keep this ability
forever, even over reboots?

> I'm proposing flat files initially for simplicity, but planning to
> evolve it into an object store in the long term.
>
> > > Concretely, instantiating an app might work by creating a new file in
> > > a directory in ~/.config which would list:
> > >  - the zero-install URL of the application to launch
> > >  - public keys to trust when fetching program code/data
> > >  - pet name
> > >  - files/directories to grant the app access to when running it
> >
> > Per-program keys is an interesting one. So far I've resisted, because
> > the extra confirmation dialogs might be counter-productive.
>
> 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.

On the other hand, the simple information that 'this interface is
still signed with the same publically announced key as before' is
quite useful. We have a hints box in the 'confirm trust' dialog that
provides this information.

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


--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1