Articles / Blame the UI: Why Linux is …

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

It's easy for Free Software users to laugh at the misfortunes of their Windows-using colleagues as they suffer through the virus du jour, but if you can set your superiority complex aside for a moment, can you point to anything in Melissa/ILOVEYOU/etc. that couldn't be accomplished by a badly-written MUA running on Linux? In today's editorial, Joe Pranevich urges the programming community to learn from Outlook's mistakes if they want to continue having the last laugh.
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.

Together, I hope, we can learn from Microsoft's mistakes.


Joe Pranevich, a "Linux Writing Person" on the side for the past 2 years, currently works in Ops for a large search portal. He occasionally dabbles in programming but lately has been writing far too much. He can be emailed at jpranevich@linuxtoday.com (@ Home) or jpranevich@lycos.com (@ Work). If you insist, you can visit his homepage at http://jpranevich.tripod.com/, but ignore the bad picture.


T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

Recent comments

25 Dec 2004 10:44 Avatar damosurfer

Re: It's more of a user education problem
I'm just a plain user, but here's a thought...
Wouldn't the whiping out of the user's home dir be solved by having a special user with nothing in their /home just for program compilation?
If the Makefile is malicious it wouldn't have anything to destroy...
my $0.00000000002 :-)

17 Mar 2001 01:49 Avatar gurubonz

Re: ./configure; make all; su root; make install... untar backups...

> I write "vi-rus", a neato app that
> does something innocous (maybe draw
> ascii pr0n).
> I can expect most people to install it
> as root (all I need to do is put that in
> the README),
> I have it email me `uname -a; ifconfig
> -a; ifconfig; netstat -a`, append a new
> line into
> /etc/passwd (and possibly
> /etc/shadow), and next thing you know, a
> ton of shell accounts.
> Very simple to perform, possibly a
> couple days of coding (I still need a
> real app for "cover")
>
> It might be days before it is noticed
> that this isn't a legit app. The people
> at Frshmeat
> would remove it, everyone would pat
> themselves on the back for their quick
> reaction time,
> and I would keep my root shells :)
> Everyone is happy (well, almost everyone
> ;).


Nice idea except for a couple of major flaws :)

Flaw number one The only thing I do as root when installing a package is make install.

Flaw number two. I have a router which I never install new software on. It has a real ip, but all my developmental machines are masqueraded through this box making direct access from outside my LAN impossible :)

Flaw number three. How many unix users have /etc/securetty

/etc/hosts.allow setup to allow them to telnet/ssh in from outside there own authorised network?

But yes I also was thinking of shaking up some redhat users by writing a small rpm to awaken them up by showing how easy it is to remove data. Something like Danger Will Robinson, A virus has infected your computer flashing across there screen on bootup, or replacing there lilo.conf with something that don't boot backing up the original of course & have all this explained in the documentation knowing full well most linux wanabee redhat users probably wouldn't read it till after installing and having there computer disabled.

However I'm not likely to write such a package.

too much work :(

But yes I appreciate & agree with the point being raised :)

12 Jun 2000 15:01 Avatar eacepayeakermaye

Linux is not as vulnerable. Microsoft's objective was internet monopoly.
...and their use of attachments, that require Microsoft executables,
was their main way of targeting internet dominance.

If they succeed at establishing Word-format attachments and VisualBasic attachments and other attachments as the main way of communicating on the internet then they can control the standard data formats by withholding specs and forever changing the standards. This would also require the dominant operating system to be MSWindows because no other operating system would be able to execute the attachments as reliably as Microsoft systems.

Proof #1: How often do recruiters require your resume in MSWord-format attachment instead of an HTML document?
Can Netscape produce a nice word-processing document with complete spell checking and complex formatting? Yes, in HTML.
Can it do it in MSWord-format? No. So, you better buy MSWord and
MSWindows.

Proof #2: Why did the Melissa virus not prompt Microsoft to produce an OFF switch in Outlook. Answer: Because turning off attachments would foil the
grand plan to dominate internet communication with Microsoft
attachments. So the delayed decision (delayed until ILOVEYOU)
was because the embarrasment of the virus was too great and giving up the executable-attachment strategy was difficult.
Eventually they gave in and produced the OFF switch.

11 Jun 2000 07:40 Avatar mrblonde

the user factor
lets not forget this! i am pretty much forced to run nt in my office environment (refer back to a previous post about the lack of office workgroup tools such as exchange:outlook which open source still neglects!). at 8:20am on ILOVEYOU day, i sent a mail to all users in the office to NOT open any email with the subject ILOUVEYOU in it.
sure enough, 10 minutes later my email box received 6 mails from one of the lusers in the office with *suprise.suprise* ILOVEYOU in the subject. i had to physically run to every desktop in the office and make sure that everyone else on the network who received mails from this particular luser didn't open them. fortunately most people in the office are developers and only one desktop (the original lusers') was infected.

now linux usage is characterised by more expert users who understand the difference between what may or may not be an untrusted script. as linux moves deeper into a mainstream environment and *IF* linux developers start focusing on the luser (which it really should start doing outside of the standard desktop installation) then we do indeed face the possibility of exploitation. we could be even more at threat than windows users as small open source projects are not always as rigoursly managed as windows and large open source projects. i believe that office productivity software which will be the gateway to luser virus infections need to be closely planned and managed by our bigger developers such as valinux and the boys at redhat and K.

11 Jun 2000 04:17 Avatar cptsalek

Security is always the opposite of users laziness
The problem with security is, that the user can't be lazy in any way. And admins often nows that users aren't happy when they are forced to change their passwords on a regular basis (because they have to remember the new password), and using really secure passwords is another thing, too.
This makes introducing a new security scheme to the desktop a problem, since security needs not only the users intelligence, but his/hers understanding of why there needs security and why this means to abandon a good part of luxurity.
So the question is, at least in my point of view, if there can be any security model that satisfies users wishes, or if it would be the best to prevent users from certain actions by simply disallowing them.
Lets have an example: An user opens a page containg a huge java application that needs to access system resources. Javas security model is, when I'm not mistaken, based on the concept that such apps/applets are disallowed to access them. In such cases a window is opened, displaying a message "...needs access to..." or something like that, giving the user the oportunity to grant or deny this privileges.
But if the page say "Simply grant all access...", what will the user do?
At least this would be a possibility: To grant untrusted files certain privileges, and to deny others.
Using mimetypes would be another choice, but I don't know if this is the best in general, since it is focused on just a few actions.
I would tend to a fine-grained kernel based security model, too. Let's say with installing a package out of a distro the install-scripts maintained by the package maintainer registers the application at a demon or any other instance, defining rules of what this app is allowed to do. For mail-apps this could be accessing the users mailfile /var/spool/mail/$LOGNAME and a directory where several mail-directories reside, for example ~/Mail/.
If any incoming mail would contain a desctructive script, this script would try to access system relevant files, such as /etc/passwd or would try to run an exploit. But it would definetly break the rules defined for the application that originally launched the script.
Additionally, I wouldn't focus on extensions, since they can be (as some others said before) misleading and wrong. Why not implement file as a function, scanning any attachments before they are processed? Authors of mail readers (etc...) can define a set of files that are allowed to be processed, maybe mailcap-based. This list might be redefined by the SysAdmins, too. But only with another security model behind.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.