LWN: Comments on ".desktop files and security"

.desktop files and security

andev — 2009-02-12T08:28:49+00:00

Yes!! This will come back to haunt us some day when linux is ubiquitous. Let's hope it gets fixed soon.

sandbox != capability access control

zooko — 2006-08-09T23:11:13+00:00

Indeed. The idea is to allow dancing pigs, without thereby also allowing theft or destruction of your data, illicit use of your network, etc.

See "Polaris" and "plash" for examples.

sandbox != capability access control

vonbrand — 2006-08-09T18:41:54+00:00

This is nonsensical... expand the limits according to what the user asks to be expanded? I.e., allow dancing pigs if asked?

sandbox != capability access control

zooko — 2006-05-19T03:40:04+00:00

Perhaps Alan Karp did use that terminology. Indeed, the first sentence of http://plash.beasts.org says "Plash is a system for sandboxing GNU/Linux programs.".

However, Plash (and Polaris) are doing something new that the Java sandbox paradigm did not do, namely dynamically extending the privileges available to the constrained code by observing what actions the user is asking the constrained code to perform.

We ought to use different terminology in order to make it clear to people that Plash and Polaris are not merely another attempt at implementing the failed Java sandbox paradigm. I've already made this suggestion in private e-mail to Mark Seaborn (of Plash). Now I'll make the same suggestion to Alan Karp.

Regards,

Zooko

sandbox != capability access control

pimlott — 2006-05-19T00:14:02+00:00

I agree with the first sentiment--thanks, Jon, for pointing out Plash! I think this has better potential to improve security in practice than SELinux. I'm a little confused about your second statement, because I didn't think that sandboxing had such a narrow meaning. I think I even heard Alan Karp describe Polaris (on which Plash seems to be modeled in part) as a sandbox.

.desktop files are simple metadata

droberge — 2006-04-11T18:54:58+00:00

.desktop files aren't scripts; they really are only simple files with key=value pairs. The security problem comes from one of those values being an arbitrary command line and another one being an equally arbitrary image file to use as the icon.

So, say, we could have one with Exec=/bin/rm -rf / and Icon=/path/to/jpeg/icon, which will look like a JPEG image but actually be a data-munching program invocation.

Security Risks and Human Nature

jmorris42 — 2006-04-10T19:04:48+00:00

> In the end, there are always trade-offs between security and usability...

Granted. But this one is simple to decide as soon as it is described. We have a file that can appear as anything it wishes to inside the graphical environment as both the icon and caption text being totally decided by the .desktop file itself, while the user has little or no way to discover what it will do when activated other than actually activating it or dropping to a command line and invoking less on it. But it can do absolutely anything it wants with the full execution rights of the user without requiring any privleges other than to be readable. So just what is the point of retaining the execute bit in file systems if this stands?

.desktop files and security

cortana — 2006-04-08T23:02:45+00:00

When extracting from an untrusted archive, tar, unzip and similar should be invoked with a sane umask that prevents the creation of executable files.

.desktop files and security

brouhaha — 2006-04-07T21:46:50+00:00

I think there are obvious reasons why it is desirable to have a standard for files representing desktop icons. The question isn't "why do these files exist", but "why do they have to be written as scripts"?

The Macintosh had desktop icons since introduction in 1984, and they didn't (necessarily) have executable scripts or programs behind them.

The .desktop files only need to contain some simple metadata; it would be much more appropriate for them to be XLM, or even simple text files containing key/value pairs.

.desktop files and security

job — 2006-04-07T19:49:18+00:00

Why do these files exist at all?

Security Risks and Human Nature

smoogen — 2006-04-07T19:19:07+00:00

In the end, there are always trade-offs between security and usability... and trying to figure out where you havent just loaded your double barrel shotgun and aimed it at your crotch can be a lot harder for people because humans have myopic vision of wanting to get stuff done.

Humans also have horrible risk assessment skills. Many of us verge on climbing into the hole and welding it shut, and an equal many do not see the risks until after they have 'survived and gotten stronger, or didnt survive and doesnt matter'.

Trying to figure out the middle ground is the hard problem that we have to realize that people on both sides arent going to be happy with.

ease of use vs. security

dank — 2006-04-07T15:34:57+00:00

th0ma7, the problem is that malware can easily
create or modify icons. It might not be a
problem for you now, but this is a security
issue worth looking at carefully.

.desktop files and security

smoogen — 2006-04-07T14:30:00+00:00

Hmmm I dont think the executable bit would be the fix. The .zip attack is the way to get around that. Send the person a .zip file and they extract the stuff from it. Voila, the user pulls out the executable code with the appropriate bits/extensions in it.

Yes it involves the user.. but this attack works 30% of the time from what I can tell from cleaning up windows machines.

.desktop files and security

th0ma7 — 2006-04-07T03:41:22+00:00

We have plenty of 24/7 production linux workstations at my job and let me say that casual users really only want to click on a easy to understand icon... The extension/security is something that our users really dont want to get involved with... they only want to get their job done.

I don't get coments like:
The ability for a program to present any icon to the user IS definitely a problem;

The ability for a user to use a program is to activate it in an easy manner... and this is, by far has I know, almost everytime represented by an icon on a GUI... unless we go back to a console using vim?

.desktop files and security

jmorris42 — 2006-04-06T21:17:33+00:00

> So yeah, this is quite bad. I say that making .desktop files into real
> #! scripts with an executable bit is the way to go.

Plus by beating them over the head over this we just might impress on the clowns making the desktop environments that there is some value in retaining UNIX culture. This is a perfect example of the saying "Those who do not understand UNIX end up reinventing it... poorly." There are reasons for those executable bits, obviously some GNOME didn't understand that. And if it is 'executable' it should be runnable from a shell so it needs the #!. Again, the graphical folk have this religious belief that the command line is bad, and their ultimate goal is to eliminate it. We who believe in UNIX, everything is a file, yada yada have to push back hard now or admit defeat and load OpenBSD.

sandbox != capability access control

zooko — 2006-04-06T15:35:08+00:00

Plash is showing the only hope for the way forward. Please don't confuse sandboxing (applet can't do anything that the user might regret) with capability access control (applet can't do anything that the user hasn't indicated he wants it to do).

.desktop files and security

remijnj — 2006-04-06T15:06:50+00:00

Another possibility would be to mark known-good .desktop files with an extended attribute. If an attempt was made to launch an unmarked file, a suitably scary dialog would be put up and confirmation required from the user.

Given a choice between dancing pigs and security, users will pick dancing pigs every time.

.desktop files and security

erich — 2006-04-06T12:23:04+00:00

they aren't as cross-platform as they should be anyway.

For example, KDE apparently doesn't support .jpg files as icons, which totally sucks for album art. Which is the only case where I have used .desktop files so far, to display album art as folder icon.

.desktop files and security

Los__D — 2006-04-06T10:32:22+00:00

100% agreed, this is something most of us would have pointed fingers at M$ for doing.

This can't be allowed to happen much more than once, or world dominance will come with loads of desktop systems overtaken by nasty scipts and other malware (And then probably lost again just as fast, as it seems to be one of the top reasons people and companies are considering the switchover. Let's give them a chance to see the rest of the wonders before they regret, eh?)

Dennis

.desktop files and security

kitsilano — 2006-04-06T07:05:06+00:00

I think the executable bit is a simple and unixoid way to solve the problem. You can still use all the flexibility build into the .desktop file. You could even run it from the shell. And any hostile .desktop files sent you by email has to be made executable, like any other executable sent to you. And if the Desktop Environment does not interprete a nonexecutable .desktop file and shows a scary icon, the security will be good enough.

.desktop files and security

jmorris42 — 2006-04-06T04:17:06+00:00

> It is not clear that everybody sees a real problem with the capabilities
> of .desktop files.

And if we wait up for the congenital idiots who can't see the evil possibilities in the present situation we will calcify the present crappy situation in stone and be dealing with the consequences for a decade. If anyone wants to know what that future looks like they can boot a virgin install of Windows, connect it to a bare cable modem and wait an hour. This is an easily exploitable problem, we just have to pray it gets fixed before it gets used in the wild.

We all laughed when Microsoft thought it would be a neato idea to hide file extensions. Folks, this gets fixed or someday we are going to get the biggest comeuppance ever imagined. As currently implemented .desktop files are little suprise packages. Some versions of GNOME don't even provide an easy way to see what one is going to do before you launch em.

Security isn't something you do as an afterthought. What were they thinking? What were they smoking! Whatever moron originally implemented this mess needs to be blacklisted from contribution to a major project for at least a decade. Security by design needs to be the watch phrase.

Ok, had to get that rant out of my system...... :)

.desktop files and security

tetromino — 2006-04-06T03:32:35+00:00

At first, when I read the .desktop file spec, I didn't understand how horribly insecure these things are. I mean, the Exec parameter is just the name of a program and parameters. There is no shell syntax, no substitution. How much damage can that possibly do?

And then I realized that the program can be /usr/bin/perl. And the parameters can be -e and 'ANY_ARBITRARY_PERL_SCRIPT'

So yeah, this is quite bad. I say that making .desktop files into real #! scripts with an executable bit is the way to go.

.desktop files and security

mrshiny — 2006-04-06T03:07:23+00:00

The ability for a program to present any icon to the user IS definitely a problem; witness the spread of trojans on Windows platforms because of the default setup of Explorer (it hides file extensions). Users often click on what they think is a JPG when it is actually a program. Recent versions of Internet Explorer go to some lengths to try to inform the user that the file they've just downloaded is a program and it might be dangerous. Whether or not this feature works fully as intended, it is a step in the right direction. GNOME and KDE developers should take note of this issue, because it will affect their users as much as it has already affected Windows users.

LWN: Comments on ".desktop files and security"

.desktop files and security

sandbox != capability access control

sandbox != capability access control

sandbox != capability access control

sandbox != capability access control

.desktop files *are* simple metadata

Security Risks and Human Nature

.desktop files and security

.desktop files and security

.desktop files and security

Security Risks and Human Nature

ease of use vs. security

.desktop files and security

.desktop files and security

.desktop files and security

sandbox != capability access control

.desktop files and security

.desktop files and security

.desktop files and security

.desktop files and security

.desktop files and security

.desktop files and security

.desktop files and security

.desktop files are simple metadata