"Name" key value in desk. entry spec collides with file names, could misguide users?

[Kalle Vahlman]

On Sun, 13 Mar 2005 16:50:34 +0100, Diego Calleja <diegocg at teleline.es> wrote:
> El Sun, 13 Mar 2005 09:00:26 +0200,
> Kalle Vahlman <kalle.vahlman at gmail.com> escribió:
> > >    Bug: He'll get a warning because he's trying to overwrite "foo.desktop" with
> > > "foo.desktop". User was just seeing "foo" and "bar". He'll never know that "foo"
> > > and "bar" had the same name and he won't know how to drag panek's foo.desktop
> > > reliably.
> >
> > This is annoying when encountered, true, but how often would a user
> > see this? The "user way" of creating .desktops is through some UI,
> > which at least on GNOME creates a random name for it. The application
> > provided .desktops could have this problem, but why would you have two
> > of them in the same place (and not want to overwrite)?
> 
> I don't know other people, I don't use gnome "methods for creating a new .desktop file"
> I just drag/drop from the menu. I expect users to do the same, and I bet there're people
> hitting this. I hit it by using gnome for 30 minutes, it's not a "theorical problem"

If you drag them from the menu, they most likely are for the same app
(if they have the same name). I see no problem there.

The question remains open: How do you get two .desktops of the same
name (but different Name field) if you don't create at least one of
them by hand?
 
> > So this is somehow different from the situation that I decide to name
> > my newest malware executable as "Natalie Portman Nude.jpg" and users
> > click on it trying to view it with the default viewer?
> 
> Viewer will try to open it and will fail.

No it won't. Nautilus detects it's an exe and complains of the mismatch.

So I was actually wrong with that argument (which I'm only glad of :)

> Quoting from: http://primates.ximian.com/~miguel/archive/2004/Sep-09.html
> "Security: [...] Certain things in the Gnome world have been hard explicitly to avoid
> problems of this nature (the never-shipped and luckily-defunct executable-mime-type
> handler is one example)"
> 
> .desktop brings to use the problem again - .desktop files are itself a "executable mime
> type handler". They're "exectuable" as long as they've a "Exec" key. The difference here
> is that it's even *more* easy to hide them. Example:
> 
[snip trojan mail]
> 
> It's *exactly* what window viruses do: autosend themselves attaching a hotgirl.jpg.pif
> file. People looks at hotmail (let's forget outlook), downloads the file, and tries to
> open it. Boom.

Yeah. And that is by no means the .desktops fault, no more than .pifs.
It's the stupid user that does the work. I would never open anything
sent from a hotmail acccount, but most people would. How do you
protect users from downloading an archive, unpacking it and *then*
running the malware?

Right, you don't.

> You claim that:
> > The only way to Be Sure (tm) currently is to only use
> > software/anything from a trusted source.
> 
> And I think that this assumption is broken. ActiveX designers though the same, "hey,
> this is not dangerous, users will decide if they trust unsigned activex controls or not".
> Mail addresses can be spoofed to, and that's not going to change tomorrow either.

If someone actually believes that anything gotten from the web is
safe, the person is broken (I know, lots of people do. They are still
broken).

> The first problem it's not so important. The second one it is, I think that it's a
> security issue. I'm supossed to work with computers, so if in the future linux holds
> an important desktop share I don't want to spend my work hours running
> GNUspywaredetector. IMHO, the whole desktop file specification needs to be
> rethough: symbolic links, posix attributes...?

Hardware DRM, digital verification keys by an authority, some other
nonsense that works or doesn't...

Really, how secure your system is, if this compromises it?

Why doesn't

--- begin "my nude full frontal.png"
#!/bin/sh

exec malware
--- end

do it already?

Wondering,

-- 
Kalle Vahlman, zuh at iki.fi