Security issue with .desktop files revisited
waldo.bastian at intel.com
Tue Apr 11 04:17:16 EEST 2006
All files on a FAT32 system get +x don't they? (Please check) So
.desktop files will continue to work there. With noexec I think you will
not be able to execve() the files, but information about the presence of
the +x bit should still be there. Implementations would need to be a bit
careful how they check for it.
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
>From: xdg-bounces at lists.freedesktop.org [mailto:xdg-
>bounces at lists.freedesktop.org] On Behalf Of Joe Baker
>Sent: Monday, April 10, 2006 4:58 PM
>To: xdg at lists.freedesktop.org
>Subject: Re: Security issue with .desktop files revisited
>Waldo Bastian wrote:
>> On Tuesday 28 March 2006 11:27, Francois Gouget wrote:
>>> Mike Hearn wrote:
>>>> To reiterate, the security problem here is that something which is
>>>> program can make itself look like a document by using a .desktop
>>> Right, that was the initial problem. But your proposals to use the
>>> permission bit to fix it creates a lot more security issues that
>>> fix. Claiming they are unrelated is ridiculous.
>>>> The fact that +x bits have some other meaning for shell scripts and
>>> > ELF files isn't related .....
>>> The meaning of the +x bit is defined by the exec() Unix system call.
>>> does not matter to that system call whether the file is a shell
>>> an ELF binary or a desktop file. You can say what you want, it *is*
>>> When considering security issues you must always consider the whole
>>> system, not just the one small aspect you are interested in. Failure
>>> do so results in opening more security holes than you plug.
>> I think it's a sane idea to require +x on .desktop files in order for
>> browser or "Desktop" to execute the .desktop file. It shouldn't be
>> of a problem to add a #!/usr/bin/xdg-open line to the format either,
>> it my take a while before applications actually start to add that.
>What about when the KDE desktop is deployed on top of a FAT32
>which doesn't allow for UNIX style file attributes? The desktop system
>introduced this vulnerability, it should close it within it's own
>Also what about systems where the user's home directory is mounted with
>the noexec option?
>xdg mailing list
>xdg at lists.freedesktop.org
More information about the xdg