Easily solved - require that .desktop files be executable ("x" bit) [LWN.net]

Easily solved - require that .desktop files be executable ("x" bit)

Posted Feb 18, 2009 0:01 UTC (Wed) by dwheeler (guest, #1216)
In reply to: making .desktop files executable by DeletedUser32991
Parent article: Follow up: How to write a Linux virus

I agree, this is a trivially-solved problem. In fact, there's a standard solution, it's just that GNOME and KDE don't use the standard in this case. Shame, shame - that needs fixing.

If a file is an arbitrarily-executable program (as desktop files are), then the system should require that the execute ("x") bit be set before it can be run. Period. It should have a "#!..." prefix at its beginning - so the spec should add that. (If you use #!/usr/bin/env ...., then you can even have PATH redirect, but I digress).

Unfortunately, there will probably need to be some temporary stopgaps while everyone transitions to what they SHOULD have been doing in the first place. As a stopgap measure, the GUI environments could process files specially if they are executable and end in ".desktop". Also, the GUIs might accept any desktop file stored in "/usr/share/applications/", even if its "x" bit isn't set; it requires root privilege to write there anyway, so whoever put the .desktop file there was trusted. That way, the transition is pretty painless; once people have switched over, the stopgaps can be removed.

If you always run a given program to process a given file, then it shouldn't need an execute bit. E.G., a PDF reader or HTML file. Yes, an HTML file might include Javascript, but what the Javascript can do is tightly controlled (by correct implementations). Yes, a PDF reader might have a buffer overflow - but clearly that is a bug in the reader. But .desktop files can include ARBITRARY, UNMEDIATED command lines, which you're EXPECTED to run - that makes them fundamentally different.

Then, merely downloading and saving the file from the Internet does nothing - the user must then set the execute bit. Of course, this presumes that unpackaging GUI programs won't just set the execute bit on programs without giving users a chance to deal with that, but that only requires careful implementation of a very few programs.

(Log in to post comments)

Easily solved - require that .desktop files be executable ("x" bit)

Posted Feb 18, 2009 16:19 UTC (Wed) by hppnq (subscriber, #14462) [Link]

The only benefit to be had from inspecting an executable bit on an untrusted desktop file, is that it may indicate that the user has taken this action knowingly and on purpose. It seems to me that this is a very wrong assumption, one that should not be made at all.

But it gets worse, I think.

Gnome, and I am sure also KDE, already offers an interface for making files on the desktop executable. Desktop launchers are a special class of files, that only make sense in a desktop environment, and that, alas, can also be put on the desktop. The problem is, and remains also in your proposed solution, that to some users a script that sends out credit card data to some unknown website cannot be distinguished from a picture of grandmother reading the desktop specification bible, and that it will also prove a considerable challenge to these users to determine whether or not to set this executable bit.

The system, of course, does a perfectly good job of recognizing all kinds of files, and would certainly not execute files it does not recognize.

What seems a simple, straightforward solution introduces problems without removing the original problem at all: that a user can be tricked into thinking that file A is actually file B, or that file A is of type C. Your proposed solution for inadvertently running malicious programs is trivially circumvented by promising the naive user that making the file executable -- which you have made a standard action now, because there will be legitimate cases also -- allows her to install the new Tom Cruise screensaver.

Adding insult to injury, now, all launchers are a harmless waste of diskspace if I remove Gnome from my system, but not so in the proposed solution: they would remain executable even after removing the complete desktop environment (as in switching from Gnome to FVWM95) -- unless I of course also removed the new, decoupled interpreter, which would possibly result in many errors with a predictable solution, which opens up a whole new category of security issues. (And I do not just mean that in a few years, it would be like suggesting to remove Python from your system.)

It should be obvious that abusing an existing interface will never lead to a more secure system. The proper solution is suggested here already: let the user explicitly confirm that a certain program is to be run with a specific purpose. This is not a problem that is easily solved, it is much more difficult than it seems.

The proper stopgap, IMHO, is to allow launchers (interpreted as such) only in certain directories, and restrict access to these directories.

Easily solved - require that .desktop files be executable ("x" bit)

Posted Feb 19, 2009 15:51 UTC (Thu) by dwheeler (guest, #1216) [Link]

Clearly there is nothing that is foolproof. I think the key rule is that "to get the system into an insecure state, you must perform a special, unusual operation that is almost never requested otherwise, one the user would notice." (This is why Vista's whining is useless - it complains too often, training users to ignore it.) I think "setting the execute bit" can and should be a sufficiently "special, unusual operation" that it counts. "Please turn on the execute bit" should be something that normal users DON'T do, indeed, many GUI users wouldn't even know how to do it, and you could CERTAINLY put in a warning before doing it via a GUI. In contrast, "save a file from the web" is something that almost EVERY modern user does, so by itself "saving a file" should NOT subvert system security.

I agree that requiring that .desktop directories be in special trusted directories would work. However, that restriction makes .desktop files fail to work on the actual desktop, which reduces their utility greatly. And really, it seems bizarre that a .desktop file won't work on the desktop :-). But SOME change from the present seems necessary.