Security issue with .desktop files revisited

[Bastian, Waldo]

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.

Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman

>-----Original Message-----
>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
a
>>>> program can make itself look like a document by using a .desktop
file.
>>>>
>>> Right, that was the initial problem. But your proposals to use the
+x
>>> permission bit to fix it creates a lot more security issues that
they
>>> 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.
It
>>> does not matter to that system call whether the file is a shell
script,
>>> an ELF binary or a desktop file. You can say what you want, it *is*
>>> related.
>>>
>>> When considering security issues you must always consider the whole
>>> system, not just the one small aspect you are interested in. Failure
to
>>> 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
a
>file
>> browser or "Desktop" to execute the .desktop file. It shouldn't be
too
>much
>> of a problem to add a #!/usr/bin/xdg-open line to the format either,
>although
>> 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
filesystem
>which doesn't allow for UNIX style file attributes?  The desktop system
>introduced this vulnerability, it should close it within it's own
>architecture.
>Also what about systems where the user's home directory is mounted with
>the noexec option?
>
>-Joe Baker
>
>_______________________________________________
>xdg mailing list
>xdg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xdg