apt

is autopackage secure?

People often wonder whether autopackage will lead to an invasion of spyware on Linux.

To me, this question is of dubious value, because I personally believe that desktop Linux cannot ever be robust or easy enough for non-technical users whilst centralised software distribution is used. There are too many tough questions like “why can’t I get the newest XYZ feature when my friends can” (eg, in relation to Skype or an MSN client) or “why can’t I find ABC in the list” (eg, Banshee music player on Fedora). Not to mention that most distros don’t even try to provide a GUI for package management, and even in Ubuntu which has the best GUI tools of them all, they still kind of suck and break randomly.

So to ask “does autopackage allow spyware” is a silly question for several reasons. Firstly, it makes no difference if the answer is yes or no because the people most at risk from malicious software are exactly the type of people who would never use desktop Linux in its current incarnation. What’s the point of elaborate schemes to prevent spyware when they simultaneously prevent people from using Linux at all?

Secondly, it contains an implicit assumption: that the existing centralised system does prevent spyware. This is vague thinking, and was the topic of a big IRC debate last night.

I can’t reproduce the whole discussion because it was too long and touched on many different things. But I can try to summarize it all here so we can point to it later instead of repeating the same things over and over on web forums and mailing lists.

are distros secure?

The whole idea is based around a warm fuzzy feeling that the distro is run by geeks like me who would never allow software I disagree with to enter the distribution … so if end users (who are of course stupid and helpless creatures – not) cannot install software outside of their distro, we “solve” spyware. Easy!

Of course the problems and solutions are not so simple – if they were then you’d have seen a Synaptic clone for Windows years ago. In reality the problems are deep and complex, and the solutions poorly understood.

  1. First point – nobody has defined what evil software is. There isn’t even a universally accepted definition of spyware! We have to talk about Evil in general terms because if somebody figured out a totally rad system to block spyware, within 5 minutes somebody else would be saying “but why doesn’t it stop adware too?!” or “what about dialers?”.

    A good illustration of this – on IRC somebody said words to the effect of “nearly everything phones home these days, even printers, so stopping spyware on Windows would be really hard”. But this conflates one thing (phoning home) with a related but different thing (spyware). Legitimate programs like Firefox also phone home.

    There’s another – vital – reason to create a definition of Evil. If there isn’t one, application developers have nothing to work against. How can they know whether putting adverts in their program like Opera does is regarded as an illegitimate practice or a legitimate business model? What about popup adverts? What about a P2P program whos development is explicitly funded by popup adverts that appear when it runs in the background (and the user is informed at install time)? Where do you draw the line, and how do you avoid changing the rules after the game has started?

    This is why I’ve been making a start at writing a definition of Evil, in a previous blog entry.

    Conclusion: before we can solve a problem we must understand it, and that means we must define it

  2. Second point – distributions do not exclude software on the basis of “morality”. Instead they exclude on the basis of license, and sometimes random other reasons. For instance Red Hat don’t ship Novells reimplementation of a well known companies technology (.NET), but they do ship their own reimplementation of a well known companies technology (Java). There’s no legal or policy basis for the exclusion of software in any existing distribution.

    Conclusion: when it comes to the crunch, distros won’t do what these people expect

  3. Third point – adware isn’t just for proprietary apps. You may think that because most distros only include Free software, that unethical behaviour is a solved problem …. but you’d be wrong. There’s nothing in the definition of Free software that prevents people from bundling pop up adverts with their program and after all if you’ve worked long hours to write some most excellent software why not get paid for it? Many open source websites already include Google AdSense adverts, it’s not a big stretch to see adverts in the programs themselves.

    If you want a clear example of that, during the whole WordPress fiasco, the software was not removed from Debian. I think it’s obvious that spamming Google for profit is unethical behaviour for a program.

    Conclusion: what makes people think that unethical software cannot be installed if even users of the most legally anal distribution around contains it?

  4. Third point – the issues don’t stop there, oh no. We’ve barely even got started. In fact, the Debian ChangeLog entry includes the line “Changed upstream’s default links. Controversial?”. So you may say, well spyware cannot be a problem on Ubuntu because you can only easily install Free software, and Free software can always be patched to remove nasty advertising or unethical behaviour.

    But wait – who ever said advertising was unethical? The WordPress author did it in a covert way because he knew people would object. But what about our hypothetical P2P application which is GPLd but has a full time hacker, funded by pop up adverts that appear when the program is running. What if users like this feature because they know the program is as good as it is because of the funded developer? One persons annoying advertising is another persons salary, and who is to say opinion will always be unanimous on whether it’s right or wrong? Was Opera wrong to have advertising? What if it tracked your browsing habits server-side and fed you customized adverts? Is this spyware? Is it adware? Should it be “blocked”?

    Conclusion: being a part of the in-club in major distributions is nice, but it reflects a black/white divide where none exists. Distributions that attempted to enforce some code of morality by making it hard to install non-packaged software for “security reasons” would soon run afoul of the greyscale nature of reality.

That’s just the philosophical issues

I could continue with them. But there are some simpler objections too.

Having centralised packaging hosting and build servers is a massive central point of failure. Debian servers have been cracked before and it’ll happen again in future – the nightmare scenario is somebody compromising a build server and then silently modifying the compiler, without being noticed. That system can then insert backdoors into every compiled program (or just a few). This attack was first outlined by Ken Thompson “Reflections on Trusting Trust”.

And most screamingly obvious of all, it doesn’t scale. There’s a simple test you can use to help determine if an idea is any good or not: “would it work if everybody did this”. A simple translation to our scenario is “what would happen if Microsoft did this?”. Imagine if Vista shipped with a new anti-spyware feature in which only software downloaded from http://download.microsoft.com/ could be installed. Microsoft would require every software developer to submit their program to them, and they would reserve the right to drop or modify any program in any way at any time, without notifying the original authors. Of course, people would go beserk, the massive abuses of power it’d allow would simply be unacceptable. This is exactly the scheme the Linux community, “defenders of freedom”, promote every day.

It’s ironic that our primary competitor could never implement the schemes we use because it would be too monopolistic.

is it hopeless?

No, of course not. Solutions do exist. The ultimate solution is of course the same one we use to stop most undesirable behaviour – the law. Unfortunately the law hasn’t quite caught up with Internet Time yet, and due to the international nature of the ‘net it’s a bit hard to enforce rigourously anyway. That’s even assuming the lawmakers can agree on a definition, a solution and how to enforce it! The DMCA showed quite clearly the dangers of bad lawmaking in the digital age, so we don’t want anti-spyware legislation to be rushed through if it’s poorly thought out.

Until then, we need to make do with what we’ve got. Lots of discussions around this topic have come and gone on autopackage-dev over the years, and many interesting ideas have been floated including:

  • Package whitelisting networks: this is a distributed variant of the “only authorized software” idea. Like SSL, root certificate authorities use PKI to sign software releases. Software that isn’t signed won’t be installed by the OS (or installs with a warning). There are lots of problems with this approach, as has been covered previously.
  • Origin point blacklisting. This is a band-aid that could be implemented quickly and might help stem the flow for a while. Or it might not. Hard to tell.
  • Lockdown – assume the worst, that the software is out to screw you over, then jail it so that it can’t (whilst still letting useful software do what it needs). This forces control back into the hands of the user – nobody tries to define at what level advertising or tracking becomes unacceptably intrusive, instead, software is prevented from tampering with the operating system internals so it can be quickly and accurately removed. This puts the user back in control and pushes policy decisions back onto them.
  • Show user ratings/opinions before installing sofware, giving users distributed advice on what the software does and how it works.

None of these are perfect solutions: usually, there’s a balance between effectiveness and implementability. And some have other problems. Maybe I’ll talk more about them in future.

7 Responses to “apt”

  1. Rack Says:

    “For instance Red Hat don’t ship Novells reimplementation of a well known companies technology (.NET), but they do ship their own reimplementation of a well known companies technology (Java). There’s no legal or policy basis for the exclusion of software in any existing distribution.”

    This is a poor example because this is in fact a legal issue. Whether you understand the legal issues involved in a detailed way to make such a claim is a different thing. Very few people do but to suggest that this is somehow non legal is not a misleading claim

  2. Mike Says:

    Red Hat say it’s a legal issue indeed, but apparently Novell and Canonical disagree. Moreover, Red Hat won’t explain exactly what the issue is.

    Anyway, I think you’re dwelling on the precise example. There’s no obligation for them to explain their actions and as a result they don’t – distros can and do drop or modify any software at any time, which I find unacceptable.

  3. Creo Says:

    “Red Hat say it’s a legal issue indeed, but apparently Novell and Canonical disagree. Moreover, Red Hat won’t explain exactly what the issue is.”

    Ya right. If you ever learned anything but legal issues it is that you dont explain everything in minute detail because everybody who wants to try and poke holes will do that anyway and nitpick. Mp3 support for example is very clearly explained and still hasnt resolved anything at all except more people asking about stuff they dont really have a clue about.

    “Anyway, I think you’re dwelling on the precise example. There’s no obligation for them to explain their actions and as a result they don’t. distros can and do drop or modify any software at any time, which I find unacceptable. ”

    Yes people are dwelling on it because it is FUD. Every package being moved in or out of the distribution has precise reasons. People just dont drop stuff out of their fancy details. For fedora anything being moved out of core can be maintained by anyone interested in it as long as it is open source and legally unencumbered. Come up with a better example next time

  4. Mike Says:

    MP3 support was never clearly explained – other than “patents” which is too vague. The real reason as explained to me was that there are no good BSD/X11 licensed MP3 decoders, and it’s the incompatibility clause in the GPL that causes problems. So Red Hat would be happy to ship a BSD licensed MP3 decoder.

    And I’m sorry but I don’t consider “people will poke holes” to be a valid reason for not explaining something – for hopefully obvious reasons!

  5. creo Says:

    “The real reason as explained to me was that there are no good BSD/X11 licensed MP3 decoders, and it’s the incompatibility clause in the GPL that causes problems.”

    What the heck. Its quite suprising. ever seen http://mp3licensing.com/. look up the patent numbers some time

    “And I’m sorry but I don’t consider “people will poke holes” to be a valid reason for not explaining something – for hopefully obvious reasons!”

    You just basically made the assertion that you dont even consider mp3 patents a good reason to not ship it with Fedora or Debian or Ubuntu by default. So its useless even bothering to try and explain legal stuff to any layman.

  6. Mike Says:

    I did no such thing. Please be precise in your characterisation of other peoples arguments. To recap, I said:

    * Red Hat ship a Java reimplementation but not Mono, and Novell vice-versa
    * Red Hat have never satisfactorily explained why not, except for generic “it’s the lawyers” handwaving
    * This is bad

    You are the one who brought MP3 decoding into this and no, it is NOT well explained, the official answer is here:

    http://fedora.redhat.com/About/

    “The Free and open source multimedia codecs such as the Ogg family of codecs are superior, and they are not patent-encumbered. Never have been, never will be. That’s why we support Ogg Vorbis (lossy) and FLAC (lossless) for general audio, Speex for speech, and Ogg Theora for video.

    For those people who insist upon using mp3, it’s not difficult to figure out how to get these players. Still, we’d much rather change the world instead of going along with it.”

    This is a very poor answer, not only does it completely gloss over the issue of X11/BSD vs GPL licensing and patent clauses which Havoc Pennington has identified as the root cause before, but it comes off as incredibly arrogant.

    Anyway, you took us off on a tangent. The core issue is that distributions can and will drop any software at any time, as they see fit, and there is no requirement for them to explain or justify their actions. Which is bad!

  7. Mike’s Journal » Blog Archive » qed Says:

    [...] A few weeks ago I did a post about apt-get and security, and how autopackage affects all that. [...]

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: