Security issue with .desktop files revisited

[Mike Hearn]

Francois Gouget wrote:
> So in the above scenario, when the user downloads the rogue '.desktop' 
> file to his desktop, that file will be tagged as 'untrusted'. Then, 
> clicking on it would warn the user before running it. .desktop files 
> shipped with the distribution would not have the 'untrusted' bit and 
> thus would not issue this warning. Also, this warning could be 
> selectively issued only for .desktop and 'executable' files, and not 
> if the file is merely a simple jpeg. But that could be configurable 
> and a 'paranoid' setting would warn for all untrusted files (in case 
> they are designed to trigger buffer overflows).
>
> Such a solution requires quite a bit of work and time to be 
> implemented but then I think any solution to this problem do.
Yes, this is a variant on the +x bit marks a file as trusted.

Here's an  idea - the problem with requiring an EA or +x to be set is it 
breaks backwards compatibility (it'd break Crossover/Wine for one ...). 
But what if the logic is inverted - so the absence of +x means a file is 
trusted, and web browsers or email programs set +x when they save a file 
to disk? The +x bit on a .desktop file in the users home dir is then 
treated as a "don't trust" marker. This doesn't break backwards 
compatibility and only requires that web browsers and email programs be 
patched.

I'd still be happier with some solution that prevented a .desktop file 
masquerading as a JPEG file, but anything is better than nothing ...