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…
]]>(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!
]]>“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 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.)
]]>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?
]]>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.
]]>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.
]]>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)?
]]>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.
]]>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?
]]>