Based on a casual reference from Edd Dumbill, I thought I’d check out the Zero Install system he mentions.
It starts out as an intriguing concept. There are obvious security implications, though, and they seemed to have addressed them here. Unfortunately, that page makes the following mistake:
Only the Zero Install software itself is a potential risk to system security. With traditional (non-zero-install) systems, every application, library and documentation package is a potential root compromise.
Of course, this system is all about downloading software off the Internet and running it on your local machine, every piece of which is a potential risk to system security. Thus, this particular “fact” is snake oil, and these people now have a very high burden of proof to overcome before I consider their system trustworthy.
It’s tempting for people to think they’ve solved a particular security problem just because they handle it better than other people. There may be benefits to the Zero Install approach, and they may even be a theoretical improvement over other systems. But “almost right” doesn’t cut it in security, and if they’re amateur enough to make claims like the above, why should I believe that their execution will be any more competent?
“Of course, this system is all about downloading software off the Internet and running it on your local machine, every piece of which is a potential risk to system security.”
But no more so than users installing stuff to their home directory, which they can already do. If your system is insecure in that regard, then obviously Zero Install won’t fix it. It’s just a cache, like squid; there are no additional risks from the software that gets pulled into the cache over using the same data without the cache.
I’ve added an extra bullet point to the page. Does that make it clearer?
No, it doesn’t. Maybe you can restate it to emphasize the fact that you do have a validation system for downloaded software, or something, but you seriously need to purge yourselves of this idea that your Zero Install software is the only vector of attack.
I’ll try to explain it to you a different way. The digital signatures on ActiveX do not make ActiveX secure, because binary verification is not sufficient. All new software is a potential security risk, whether it’s installed via your Zero Install system, via apt, via an InstallShield installer, or whatever. Certain methods of installing software are more risky than others, and some might even be considered “safe” for the most common threat models, but none are truly foolproof.
By claiming otherwise, you are telling me that your attitude towards these potential issues is to hand-wave, much like Microsoft did with ActiveX. This impairs your reputation for seriousness about security issues, which makes me very cautious about trusting that your software will consider obscure security issues properly.
The section you quote from is “system security” (as opposed to “user security”, which is detailed below that). Users installing software through zero install do not risk the system security any more than installing to their home directories without zero install. ie, there is no added risk over a system where the admin refuses to install anything.
Think of Zero Install as a specialised/extra-efficient version of squid. Zero Install does not provide any way to mark an executable as special (like SUID in normal filesystems). Can you suggest an attack a user could launch against a (bug-free) Zero Install system that they couldn’t launch against a normal system (to which they don’t have root access)?
When you talk about the relative security between Zero Install and other ways of installing software, you’re in good shape. When you talk about some aspect of your system having zero risk, you lose me.
I don’t care about meaningless distinctions between “user” and “system” security (as if user security was less important, or as if there haven’t been scads of privilege escalation vulnerabilities). When you say “the only risk is right here; there is no risk there”, you are selling snake oil. That you are selling snake oil to yourself as well makes it no less dangerous.
Again, for emphasis: LESS risk does not mean ZERO risk.
It’s obvious that Zero Install doesn’t protect you from kernel security bugs, etc. But these bugs are entirely independant of it. You could easily say that running ‘ls’ presents no risk to system security, for example, without mentioning kernel bugs, glibc bugs, gcc bugs, hardware bugs, etc. Of course, if a system can be exploited already, and then you add Zero Install, it can still be exploited. This is true for all programs. If I tell someone “there is no risk from running ls”, I don’t mean that they can’t have a heart-attack while doing so. It only makes sense to document security problems that are introduced by a system, not ones that were already there.
Zero Install’s design protects you from system security problems introduced by root-install systems like RPMs or Debs. That is the only claim that is made.
As for ‘user’ problems being important: they are listed right after the ‘system’ bullet points. Separating out the two issues is necessary to understand the risks. If you don’t believe that they should be treated differently (due to possible kernel bugs), why not let users run as root whenever they want? Clearly, a process running as root is a much greater risk than one running as a user which could exploit some currently-undiscovered kernel bug to become root. User-level problems are covered in depth in the article.
It’s obvious…
If you’ve gotten this far into this conversation and haven’t gotten that it certainly isn’t obvious from the statements you make on your site, then I feel even more certain that I read you guys right in my original article.
So far, I have refrained from making a single statement about your actual technology, its pros and cons. I don’t know whether it’s an improvement. From my quick skim, I’m not convinced that you even provide much of a security benefit over package management, but I’ll freely concede that I have nothing to back up such a claim.
I am purely talking about the impression I get that you don’t take security seriously. Part of taking security seriously involves being very clear and precise in your claims, which you aren’t being by claiming “no” risk over here and then saying things like “Oh, but it’s obvious that I didn’t mean that.”
Another part of taking security seriously is understanding what, exactly, people are criticizing when they criticize you. That you are responding with claims about your technology tells me that you don’t have a clue why I objected to your statement.
So, if you want to continue this conversation, tell me: why do you think I reacted the way I did in my original article?
Perhaps you can suggest a better wording, then?
The current text (and remember that this is a bullet list; nothing too long here please) is:
# Only the Zero Install software itself is a potential risk to system security when installing software for users. With traditional (non-zero-install) systems, every application, library and documentation package is a potential root compromise.
# Without Zero Install, users still have the ability to download programs to their home directory and run them there. Since your system already has to be secure against this, such attacks aren’t considered security risks from Zero Install.
The section is on the design (not implementation, which is below) of zero install. It is for system administrators wondering what risks *they* (not their users, who are covered below) face installing zero install. The claim is that installing a correct implementation of zero install will not allow any attack that wasn’t already possible (ie, that installing it is ‘safe’ for the system; there are no additional risks).
I don’t see any claim here that zero install removes existing risks (fixes kernel bugs, etc). In fact, it now (after your first post) explicitly states that existing risks from users aren’t affected.
(Why do I think you reacted the way you did in your original article? I don’t know about you personally, but from experience I’d guess that you’re a long-time user of apt/yum/emerge/whatever and feel hostile to other systems (“Snake oil” is quite strong), especially new ones which you feel further fragment an already over-fragmented situation, and threaten to divert packaging work away from your familiar format. I could be wrong, of course.)
It’s hard to make suggestions without understanding your security model better. The part where you claim no risk is what gets me. Perhaps this:
“Software provided by Zero Install is installed without requiring special privilege, which reduces the risk of installation compared to traditional package managers.”
That’s a narrow claim that doesn’t imply that you think your software is impregnable at some point.
I don’t know about you personally, but from experience I’d guess that you’re a long-time user of apt/yum/emerge/whatever and feel hostile to other systems…
Well, you’d be partially right; I am a user and developer on apt. But I had nothing against Zero Install coming to the Web site. Indeed, I was thinking of grabbing a copy and trying it out, and maybe packaging it for Debian. Not a negative thought was in my mind until I read the excerpt I quoted.
That would be another example of a dangerous attitude–the idea that strong criticism cannot be honest. If you are not able to take strong criticism at face value, then I wish you luck when (not if, assuming you gain an installed base of any size) your software is cited for its first serious security weakness.
“Snake oil†is quite strong
Yes, but it’s also accurate. (I might now say, “dangerously mistaken” instead of “snake oil”, but I doubt you’d like that better.)
The claim was only no added risk by *design* (you quoted out of context). We’re very clear about implementation risks (the first thing you see on the download page is a warning that it hasn’t been audited). Sticking a cache in a system shouldn’t (by design) force it to be less secure, so I don’t think your claim holds up. However, good documentation isn’t merely correct; it should be hard to misunderstand. Therefore, I’ve reorganised the top of the page to have two lists; one for sysadmins and one for users. I’ve removed the distinction between design and implementation risks (which seems to be causing confusion) and merged those two lists together. I’ve also added a longer introduction below the bullet lists. Better?
(What made me think you were into some other system wasn’t that you questioned the security, but that you siezed on such a minor point. Someone else might have just mentioned that they felt it over-hyped after mentioning the good points. Besides, if you don’t trust our implementation you’re welcome to write your own. It’s a pretty small amount of code. Some people care more about security than others, so focus on what you care about. Or help audit our code and/or design. We have some unit tests, but we need more.)
I must say, I’m a little surprised that Debian would include it. I find it tends to be popular with users (get the same up-to-date software easily whatever distro) and upstream (get bug fixes direct to users, and no more distributions messing up their packages; something the Wine developers complained about bitterly at the conference ;-). Smaller distros like it too (helps them compete as they don’t have to package everything themselves). But for large distros it basically means a loss of control (maybe Debian is less affected, being non-commercial).
However, if you’d like to package it, please do! We already have binary .debs, but we don’t have the resources to build lazyfs on all archs and keep it up-to-date. Having that in sid would be great!
I would not even claim “no” added risk by design. You are, after all, creating a whole new vector for installing software, and I have yet to see a software installation method that didn’t add risk.
I do like your current page better.
What made me think you were into some other system wasn’t that you questioned the security, but that you siezed on such a minor point.
Well, yes, but that’s a time-saving method for me. I don’t have time to waste on software I can’t run because it’s insecure, and I don’t have time to audit all the software I run. So I go by more probabilistic factors. Do I already run other software from this group? What’s that other software’s security record? Does the group “write checks they can’t possibly cash” when talking about their security? Do they have the appropriate level of humility that comes from being knocked down a few times?
I’m much more likely to become an early adopter if I can answer yes to the above. If I can’t, I tend to skip it until it gets a track record of its own. In your case, the quoted statement struck me as especially outrageous.
I must say, I’m a little surprised that Debian would include it.
Debian includes everything. We don’t have strategic visions or corporate policies to tell us what to do.
We’ll see. If you get a better offer from someone else, take them up on it. But if not…