| |||||||||||
Zero Install: An executable critique of native package systems (Linux.com)Zero Install: An executable critique of native package systems (Linux.com)Posted Feb 27, 2007 14:40 UTC (Tue) by vonbrand (subscriber, #4458)Parent article: Zero Install: An executable critique of native package systems (Linux.com)
I fail to see how something that allows Joe R. User to install junk into their home dir without any coordination to what is installed systemwide is of any advantage. I see it just creating a large mess overall. If the application so installed has security problems, the system as a whole gets to be vulnerable. The supposed problem with having to maintain packages for an assortment of distributions is a red herring, anyway. If the program is worthwhile, surely some volunteer will show up for managing as an (extra)official package for her favorite distribution. If they don't show up, well...
(Log in to post comments)
Zero Install: An executable critique of native package systems (Linux.com) Posted Mar 1, 2007 12:41 UTC (Thu) by Tom2 (guest, #43780) [Link] It doesn't 'allow' users to install to $HOME. Users can already install to HOME (see Autopackage, setup.sh, etc). What it does is lets users install in a controlled way (with GPG checks, regular security updates, etc) and efficiently (downloads shared between mutually untrusting users).
"If the application so installed has security problems, the system as a whole gets to be vulnerable."
Depends what you're comparing. If you're a sysadmin on a commercial system, your view of the outcomes might be:
1. User installs malware to HOME. Given an additional vulnerability in your core system, it might get root. BAD.
Even more secure would be hiding the power cable for the machine. Assuming the user isn't just messing about, and actually needs the program, the options are:
1. User installs malware to HOME. Hopefully contained in that user's account. GOOD.
"If the program is worthwhile, surely some volunteer will show up for managing as an (extra)official package for her favorite distribution. If they don't show up, well..."
Just because it's possible to do something inefficiently it doesn't mean we should. We don't need combine harvesters, because there are enough people in the world to collect all the crops by hand. But perhaps it's better to have them spend their time doing something more useful?
Zero Install: An executable critique of native package systems (Linux.com) Posted Mar 1, 2007 20:36 UTC (Thu) by vonbrand (subscriber, #4458) [Link] "If the application so installed has security problems, the system as a whole gets to be vulnerable." Problem is that even if there are no other vulnerabilities, some bot installed in the vulnerable account can happily spam away (or SSH scan or whatever) as the regular user.
Zero Install: An executable critique of native package systems (Linux.com) Posted Mar 2, 2007 12:14 UTC (Fri) by Tom2 (guest, #43780) [Link] Right, so Zero Install is more secure that the other alternatives, but it's not perfect (what is?).
How could you stop SSH scanning or spamming? You'd need a sandbox (JVM, systrace, seccomp, etc) to run the process in. But that's only useful if you can install it safely first. That's what Zero Install does for you.
If you have 'mystery.deb' and a good sandbox then you can't do this safely (the installation step may compromise your machine):
$ sudo dpkg -i mystery.deb
And you can't do this either, because the sandbox would stop dpkg from working:
$ sandbox sudo dpkg -i mystery.deb
But you can do:
$ 0launch --download-only http://mystery.org/mystery.xml
(0launch's --download-only is slightly different to apt-get's; it does unpack the files to their final (self-contained) location)
|
|||||||||||