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

[Diego Calleja]

El Sun, 20 Mar 2005 14:04:54 +0000,
Mike Hearn <mike at navi.cx> escribió:

> The wrong way is to decrease usability for no increase in security. The +x
> bit is itself a flawed idea for the same reasons: it makes it annoying and
> awkward to run things you download but does not increase security (as you
> can run software without the +x bit anyway if you know how.)

You're ignoring the key issue here: This problem is more about psychology than anything
else, its not so much about technology. Of course it's quite probable we can use magic
technology to fix it, but in the real world, .desktop files exists and people are using them
without SELinux protecting them or anything, and that's not going to change magically
unless you can make software advance magically a couple of years. Waldo's idea of
requiring the +x bit does fix a existing problem, and does fix it _today_, with microscopical
changes into existing desktop environments.

People who want to shoot themselves in the foot will be able to do it anyway by
setting +x, sure, but the problem here is that people downloads a .desktop file
by mail, they will look at its nice icon and the faked name will convince them to
double click it. For normal people setting +x it's a _difficult_ task and it's more than
enought to stop the thing, and if they do it and their computer starts doing strange
things they won't do it again, and it's easy to teach them not to do it, and it's easy
to put warnings in programs for such cases. But try to teach them that before
doubleclicking in a .desktop file they must open it with a text editor and decide if
"Exec=perl -e 'fdsfds{jhiogrew0808==#{~#2ç~#{$$@foo}}' " is harmful or not.
That is, if they see it, because they cant see the extension easily - the NAME key hides
the extension too.

Note that requiring the +x bit is something that should have happened _anyway_
regardless of security and everything. We don't execute .pl files with perl just because
their extension is .pl. I don't see what's so special about .desktop files that they shouldn't
need +x to be interpreted, and I don't agree that requiring it is a flawed idea, if anything
it should be the contrary.

Anyway, requiring the +x bit WILL improve security at the end of the day. When someone
downloads something, he won't be able to double click it and get infected because it
won't have the +x bit set. That's pretty much everything about it. It's easy to
implement, it's easy to modificate existing .desktop files, and I don't agree that it's
harming usability in any way, .desktop files is not something that people downloads
for fun and those who do should be smart enought to set +x


And I'm not talking about a "theorical issue", this is exactly the same that happened in
other systems, and that's why we know it's a problem. If I hadn't seen docens of
computers infected because "my friend sent me a file by email, and since then my
computer does weird things!" I would have never though that people would download
and double click random files from the internet, and I'd have never though that people
would be stupid enought to create viruses that spread in such ways. But it
happens - it's a fact - and we should learn from it. The +x bit provides a real fix for a
real-world problem, and what's even more cool, the +x solution it's not " quick dirty fix",
I'm surprised that the .desktop  especification didn't required it from the start.

Yes, I do agree that being able to do smarter things with technology will _help_ us - it
won't solve everything, if SELinux don't allows you to run .desktop files downloaded 
from the internet smart users won't be able to use .desktop files, and such lack of
flexibility wouldn't be acceptable for too many people. And if SELinux provides a way
of disabling this check for a given .desktop file, you're already in the same case than
setting +x by hand: People who want to run the file will do it anyway. I'd be happy
to see more helpers like those, it will be nice if Al Viro surprises us and makes
the CLONE_NS flag of clone() usable for everybody (which should allow us to have
plan9's per-process filesystem namespaces for everybody, which could be used to
"hide" things i think) but such jewels are not very common and they're far more
harder to implement, it's not easy as requiring +x.