Blame the UI: Why Linux is Not Immune to ILOVEYOU-style Worms

And the users exclaimed with a laugh and a taunt:
It’s just what we asked for but not what we want.– Unknown (Well, someone probably knows.)

These days, it seems as if everyone likes a good “Microsoft is Evil” story. I’m not going to agree or disagree with that statement in general, but this recent (and continuing) wave of email worms has given the media and the users plenty of room to criticize. Largely, these complaints have revolved around a general lack of security in Microsoft’s products — a historical truth. Adding to this anti-Microsoft inferno does not improve Linux as a whole and I believe that our time is better spent working towards ensuring that these kinds of attacks can never happen on Linux.

Linux’s Security Model

The Linux kernel has an excellent reputation for security-conscious computing. Security bugs, when found, are squashed exceedingly quickly. Linux’s low-level security is based on the classic UNIX model of users and groups. In brief, this ensures that one user can never harm another user’s files or any system files without explicit permission. Additionally, Linux ensures that no user is capable of denying service to any other user through crashing the machine, resource depletion, or a number of other more subtle approaches. There is currently work being performed to add a “capabilities” system to the kernel to make it even more fine-tunable. This model is good and very powerful, but it does not and cannot protect the user’s own files from himself or application stupidity.

The security bugs currently being seen in Microsoft Outlook are of the latter variety: application stupidity. One does not necessarily need to be running under a Windows environment to write or use stupid applications. In fact, nearly all security problems discovered on Linux systems are caused by application programmer mistakes. The Linux kernel’s excellent security helps to minimize problems caused by these mistakes (through its low-level security policies) but will never be a substitute for smart application programming and a peer review process. (In fact, some patches to the Linux kernel have actually been rejected because they provided a false sense of security despite making certain kinds of attacks harder to pull off.)

Of particular concern are either programs that are regularly granted administrative rights (such as an X Server) or programs that deal with untrusted data (such as your Web browser or email client). As Linux does not have any internal conception of “trusted” vs. “untrusted” data, application programmers must be fairly smart about it. Microsoft’s Web browser manages to deal with this dilemma at a high level, but obviously wasn’t ingrained enough to uniformly combat the problem. On the Linux side, it will be up to the GNOME and KDE development teams to make sure they deal with this issue, as they will be Linux’s flag-bearers into the future.

The Interface’s the Thing

It’s very tempting to leave the problem at that. “It’s a high-level issue caused by the march of progress into the point-and-click world of modern GUIs.” Pine users will complain, of course. The idea that one should blindly migrate from one time-tested UI model (the relatively dumb world of Linux mail readers today) into the more complicated point-and-click world seems absurd to many people. The recent events with Outlook work to further underscore that there may be fundamental defects in the way modern GUIs view the world.

The underlying metaphors of today’s most common GUIs are relatively similar. Although each OS provides a different view into the world, the fundamental building block remains the same: the mouse click. Click once to select. Click twice to open. Even when Microsoft attempted to Webify the desktop with one-click activation, it didn’t change the problem, only changed the number of clicks necessary to activate it.

The fundamental problem with this system is that it’s association based. When you activate a file icon (Using the generic verb “open” under Windows), you are performing the action associated with the file-type that you are dealing with. With HTML files, this is often opening a Web browser. With an MP3, you open a player. This tends to work out very well; with any type of document, open the viewer associated with that document type. But notice the key assumption there: It is generally implied that when you activate a file that you don’t recognize, you’ll get a viewer that shows you what it is. There’s an underlying (and incorrect) assumption that viewing a file is a read-only operation. With executable files (such as scripts), “open”-ing can be a dangerous and deadly thing!

The Document Model

Resolving the danger isn’t something that can be done at a low level. I believe that the “association” model is the real culprit in Microsoft’s recent problems, not Outlook. Users are clicking on the file (which appears to them to be a text file thanks to its misleading name) and getting exactly what they requested: executable activation. Some have pointed their fingers at the “security faults” in Microsoft’s VisualBasic scripting language, but one could easily imagine a situation in which the same damage could be inflicted with a Perl script or any other common scripting language. Having a powerful language for script writing is an asset to any OS, not a detriment. Should we ignore all the positive nail-driving features of a hammer just because you could mistakenly smash your fingers?

As a replacement for the association model, I would like to propose evaluating a “document” model instead. 90% or more of the work done by ordinary users involves documents. By “documents”, I mean the HTML files and the MP3s of the previous example; essentially anything that you would imagine could be “viewed” in the present model. Instead of clicking on an application when you want to start a new word processing document, you could click on a zero-byte read-only file of the appropriate type — essentially a template. Most users may never know the difference. Instead of executing an application when it is viewed, it makes much more sense to display it in a text or hex viewing program. It should still be possible to execute an old application with the mouse (put it on the right-click menu, for example), but that action does not belong as a default.

Unfortunately, most applications were not designed with this type of thing in mind. I have serious doubts that the Linux desktop applications of today could work this way without some tweaking. There are likely to be conceptual stumbling blocks as well. I should also say that I’m not a UI expert; there are quite likely better ways to view the world. I have decided to share this thought for the purposes of discussion. There may be other, better, ways to accomplish the same thing. Please feel free to respond to me in email or (preferably) use the feedback section of this site. I’d especially like to hear thoughts from current GNOME and KDE developers because you are the ones leading the charge into our future as a community.