General sandbox specs?

Thomas Leonard tal00r at
Sun Mar 14 22:52:23 EET 2004

On Fri, Mar 12, 2004 at 11:00:41PM +0100, Lars Hallberg wrote:
> Thomas Leonard wrote:
> >>Sorry, I was unclear here. I was so intriged by the zero install 
> >>consept. But this realy aply to a 'mother' system runing zero install, 
> >>not att all to the sandbox itself.
> >Probably. The ultimate plan doesn't involve explicit sandboxes at all, but
> >runs everything in a sandbox environment of some kind.
> If You want to run software like another filebrowser, a image indexing, 
> searching and dup recognising program, some free text indexing and 
> search utility.... that can't realy bee sandboxed?

When it tries to do the action, a dialog box pops up to confirm. So, you'd
just give the indexer full read-access to your filesystem the first time
it tried to access a private file, if that's what you wanted.

> >>If I undurstand zero install right, if somthing alreddy is in the cach, 
> >>it is just run/loaded without any check.
> >>So once aproved, its avalible to everyone!
> But if it's not [in the cache already], the download is so much overhead
> so a litle more would not matter. Given the number of possably
> interfaces, this is a strategic point to check if the file is trusted to
> install. But then the check is only performed if the file is not cached.
> Thats why i don't want to cach untrusted stuff.... but I might have got
> it all wrong :-)

Yes, that is one way, but it's bad for sharing caches, and prevents you
from just looking at a site, for example (without running anything).

People do seem to worry a lot about nasty software getting cached, but it
really makes little difference. Imagine a user who tries to run this:

$ /uri/0install/

Bad. But on the other hand, they could just as easily do:

$ lynx -source | sh -

Both can do exactly the same amount of damage, but the second works even
without Zero Install. Zero Install helps with large, complicated programs
with lots of dependancies, whereas your typical malicious program is only
a few lines long, and doesn't benefit from it.

In other words, put a warning for naive users in the interface, and just
accept that if they really want to run something they'll find a way, with
or without the cache to stop them.

> But doing the check att that point have it's own problems. Ther's realy 
> no good way of knowing how to ask the user for permision - so I guess it 
> can only fail if the file is not trusted :-(

We already pop up a dialog showing download progress (using D-BUS to
communicate with the daemon), so that's not actually a problem.

> BTW, populating /usr/bin/ etc with symlinks to the zero install cach 
> would be a way to make a system feel 'compleet' from the cli without 
> installing anything? Then it is cached as used... soo cool :-)

Yep :-)

Thomas Leonard
tal00r at	tal197 at
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

More information about the xdg mailing list