Rodney Dawes wrote:
Better yet, let's not encourage people to turn .desktop files into
scripts. As has been expressed MANY times in this thread, requiring +x
and a special tool that doesn't evaluate Exec any differently thatn we
are currently evaluating Exec, doesn't solve the problem. It is
Francois Gouget wrote:
Requiring +x on .desktop files also makes it possible to add an emblem
to the icon of those that lack it, and/or to issue a warning when the
user tries to run them. Thus this also protects users from .desktop
files that have a misleading icon.
You don't need the +x bit
On Wed, 2006-04-12 at 14:46 +0200, Francois Gouget wrote:
In order to run an executable one must have the execute permissions for
that executable. Whether you like it or not .desktop files are
executables and, as such, running them ('opening' them in desktop
parlance) should require that
We need to fix the evaluation semantics of Exec, not write a bunch of
easily-avoidable workarounds.
I don't see anything to be fixed in the 'evaluation semantics of Exec'
that would help solve this problem. Maybe if you have a concrete
proposal that can be discussed further. When
Egbert van der Wal wrote:
3) The command executed is a program/script in /usr/bin, which are
generally(but not always ofcourse) safer to use.
Like /usr/bin/perl or /usr/bin/env?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com
Rodney Dawes wrote:
actually use their computer. And .desktop files are in fact data and
not executable scripts. Requiring +x just requires you to make them
behave more like scripts.
The fact that you can write a whole shell script in the Exec= line
makes .desktop files de-facto scripts. They
On Wed, 2006-04-12 at 21:30 +0200, Thiago Macieira wrote:
Rodney Dawes wrote:
actually use their computer. And .desktop files are in fact data and
not executable scripts. Requiring +x just requires you to make them
behave more like scripts.
The fact that you can write a whole shell script
Egbert van der Wal wrote:
[...]
I would say a more appropriate approach would be to classify the command
in a few cases:
1) The command executed is a program/script in the user's home-directory
or some other user-writable location(which increases the risk of it
being malware)
2) The command
Bastian, Waldo wrote:
A viable strategy would be to start creating .desktop files with +x set
and a #!/usr/bin/xdg-open line now and then to wait a while before
environments actually start requiring it.
Please do not encourage people to hardcode /usr/bin/xdg-open. Instead,
suggest to use
Rodney Dawes wrote:
Better yet, let's not encourage people to turn .desktop files into
scripts. As has been expressed MANY times in this thread, requiring +x
and a special tool that doesn't evaluate Exec any differently thatn we
are currently evaluating Exec, doesn't solve the problem. It is
Sam Morris wrote:
A viable strategy would be to start creating .desktop files with +x set
and a #!/usr/bin/xdg-open line now and then to wait a while before
environments actually start requiring it.
Please do not encourage people to hardcode /usr/bin/xdg-open. Instead,
suggest to use
On Tue, 2006-04-11 at 19:07 +0200, Benedikt Meurer wrote:
Rodney Dawes wrote:
Better yet, let's not encourage people to turn .desktop files into
scripts. As has been expressed MANY times in this thread, requiring +x
and a special tool that doesn't evaluate Exec any differently thatn we
Sam Morris wrote:
That's really unlikely, as that way thousands of Perl, Python, etc.
scripts wouldn't work on RedHat out of the box. According to rpmfind the
coreutils package in RedHat9 provides /usr/bin/env.
It's bizarre that Fedora and Redhat differ on this point, but on a
machine
Better yet, let's not encourage people to turn .desktop files into
scripts. As has been expressed MANY times in this thread, requiring +x
and a special tool that doesn't evaluate Exec any differently thatn we
are currently evaluating Exec, doesn't solve the problem. It is very
easy to ship a
Waldo Bastian wrote:
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
On Mon, 10 Apr 2006 04:58:28 -0700, Sam Watkins wrote:
Waldo Bastian wrote:
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
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
Sent: Monday, April 10, 2006 1:27 PM
To: xdg@lists.freedesktop.org
Subject: Re: Security issue with .desktop files revisited
On Mon, 10 Apr 2006 04:58:28 -0700, Sam Watkins wrote:
Waldo Bastian wrote:
I think it's a sane idea to require +x on .desktop files in order
for a
file
browser or Desktop
Le vendredi 07 avril 2006 à 10:37 +0200, Francois Gouget a écrit :
Hi,
Vincent Untz wrote:
[...]
Not even. First KDE, at least, lets you specify multiple commands
separated by semi-colon so you could drop the 'sh -c':
Exec=/usr/X11R6/bin/xeyes;/usr/X11R6/bin/xeyes
Wow. Does the spec
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
But this is only true if the .desktop file is a valid .desktop file, no?
I guess so. I don't know what KDE/GNOME do when given an invalid desktop
file.
And if the icon is actually in the theme on the user's system?
Yes - things like JPEG file, word processor document etc are pretty much
On Tue, 28 Mar 2006 23:59:11 -0500, Rodney Dawes wrote:
The current solution in nautilus really sucks, and won't let me even
open valid files, where the extension disagrees with the data mime type
discovery.
That's a different (but related) issue, where a file extension does not
match what the
On Tuesday 28 March 2006 20:18, Thiago Macieira wrote:
Ludwig Nussel wrote:
I wonder why desktop files get 'executed' at all. Only the programs
that display the desktop and the menu need to run what's described
in a desktop file. For everything else the default action could be
just like the
On Tue, March 28, 2006 11:32, Francois Gouget wrote:
Not even. First KDE, at least, lets you specify multiple commands
separated by semi-colon so you could drop the 'sh -c':
Exec=/usr/X11R6/bin/xeyes;/usr/X11R6/bin/xeyes
Wow. Does the spec allow this? I can't help but think about what we have
Vincent Untz wrote:
On Tue, March 28, 2006 11:32, Francois Gouget wrote:
Not even. First KDE, at least, lets you specify multiple commands
separated by semi-colon so you could drop the 'sh -c':
Exec=/usr/X11R6/bin/xeyes;/usr/X11R6/bin/xeyes
Wow. Does the spec allow this?
I believe that at
Le mercredi 29 mars 2006 à 15:50 +0200, Francois Gouget a écrit :
Vincent Untz wrote:
On Tue, March 28, 2006 11:32, Francois Gouget wrote:
Not even. First KDE, at least, lets you specify multiple commands
separated by semi-colon so you could drop the 'sh -c':
I'd just like to point out that whatever is decided, it has to be
something a menu editor can implement, so it has to be something a
user can (somewhat) understand.
--
Travis Watkins
http://www.realistanew.com
___
xdg mailing list
On Tue Mar 28 10:32:25 2006, Francois Gouget wrote:
If think the solution would be to do like Windows XP SP2 does (or
maybe it is Windows 2003). When you download a file (at least using
IE and depending on your 'zone' settings), it sets some 'extended
file attributes' to tag the file as
Dave Cridland wrote:
You're certainly right in thinking this is a good solution, but it's
not one open to us, because not everywhere has extended attributes
just yet. The only common factor we have to play with on the vast
majority of filesystems is the file mode bits. Basically, the x bit
is
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'
Mike Hearn wrote:
[...]
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 ...).
Well, in my proposal, only untrusted files need the untrusted EA bit
set. So backward compatibility is not broken.
But
Francois Gouget wrote:
Well, in my proposal, only untrusted files need the untrusted EA bit
set. So backward compatibility is not broken.
Right, I'm just exploring ways to achieve that without requiring EAs.
Surely, requiring that web browsers and email tools make all the files
they save
Dave Cridland wrote:
[...]
You're certainly right in thinking this is a good solution, but it's not
one open to us, because not everywhere has extended attributes just yet.
Well, as with MAC security, this will indeed take time to put in place.
But planning ahead is good.
If a short term
On Thursday 23 March 2006 14:13, Mike Hearn wrote:
A while ago it was discussed how .desktop files made us vulnerable to the
same problems Windows and OS X have had with executable files pretending
to be data files. At the time nothing was done, as it was a theoretical
possibility. One
Mike Hearn wrote:
[...]
Surely, requiring that web browsers and email tools make all the files
they save executable cannot be good for security...
Only .desktop files, and right now +x on such a file is meaningless anyway.
Right. So now tools like wget (and shells, see below) have to know
Mike Hearn wrote:
[...]
right now +x on such a file is meaningless anyway.
One more thing, the above remark is in fact pretty insightful: normal
desktop files are not programs, neither of the shell or of the ELF kind.
They are data files. Running them does not work. Only malicious desktop
On Tue, 2006-03-28 at 14:57 +0200, Joerg Barfurth wrote:
From Solaris man-pages:
chmod(1):
[...] Only the super-user may
set the sticky bit on a non-directory file.
[...]
So neither does this bit have no effect, nor can it be set by ordinary
users.
I'd assume other
Mike Hearn wrote:
Francois Gouget wrote:
Right. So now tools like wget (and shells, see below) have to know
about KDE/Gnome internal concepts like desktop files! And you
criticize Windows design?
Not really, anything is better than nothing - does Firefox set the
unsafe EA on Windows?
At
Francois Gouget wrote:
At least Windows does not require Firefox to know about .lnk, .cmd and
.pif files.
No, and a marking scheme doesn't _require_ anything to be updated. It's
a nice-to-have-but-not-essential feature.
First, who said that worm writers are not allowed to call their ELF
Francois Gouget wrote:
Now if desktop files were to start with '#!/usr/bin/whatever', then
making the trusted ones executable could make sense.
#!/bin/false
There's also the sticky bit.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com
Ludwig Nussel wrote:
I wonder why desktop files get 'executed' at all. Only the programs
that display the desktop and the menu need to run what's described
in a desktop file. For everything else the default action could be
just like the one for text/plain, ie launch an editor.
The desktop and the
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
Thiago Macieira wrote:
[...]
Now if desktop files were to start with '#!/usr/bin/whatever', then
making the trusted ones executable could make sense.
#!/bin/false
I was thinking more of something along the lines of
'#!/usr/bin/run_desktop_file'. Desktop files are equivalent to shell
On Tue Mar 28 20:40:46 2006, Francois Gouget wrote:
I was thinking more of something along the lines of
'#!/usr/bin/run_desktop_file'. Desktop files are equivalent to
shell scripts anyway. The only thing missing is that one cannot use
them transparently because exec() does not know what to do
What I don't get is why we're trying to solve it only for .desktop
files. It's a problem for all file types. For .desktop files, we should
just make the spec more explicit on how things should get executed, and
how to validate the Exec= line. Clearly we can't just check that there
are arguments in
On Thu, 23 Mar 2006 16:36:39 +, Mike Hearn wrote:
On Thu, 23 Mar 2006 09:05:32 -0700, Aaron J. Seigo wrote:
[...]
what prevents a malicious .desktop file from using any of the other icons we
ship and pretending to be something else? looking through just the
Application icons i have on
On Sat, 25 Mar 2006 10:56:00 +, Thomas Leonard wrote:
ROX-Filer shows .desktop files (and anything else it will execute if
clicked) with a different text colour, but leaves the icon alone.
That's the sort of thing we want, I think, but does it really work? Have
you tested it on people to
Mike Hearn wrote:
Only for .desktop files without the +x bit, and that would be set whenever
a desktop shortcut is created or the user says to continue (ie that it's
safe).
If a potentially dangerous .desktop file gets through the QA process,
and is installed on an end-user system, it isn't a
On Sat, 25 Mar 2006 09:13:44 +1100, Lennon Cook wrote:
If a potentially dangerous .desktop file gets through the QA process,
and is installed on an end-user system, it isn't a leap of faith to
think that it could have +x by default.
What QA process? This is supposed to stop viruses that work
On 3/25/06, Mike Hearn [EMAIL PROTECTED] wrote:
What QA process? This is supposed to stop viruses that work by tricking
the user into thinking they're a different type of file than they really
are, as we've seen happen on Windows and MacOS X.
Sorry, misunderstood - I was thinking that a) it
On Thursday 23 March 2006 06:13, Mike Hearn wrote:
possibility. One enterprising hacker (Peter Lund) has now managed to make
a .desktop file which is simultaneously a valid shell script, in other
words, you can put any code you like in it and it'll run without any
network access. Such a
Mike Hearn wrote:
On Thu, 23 Mar 2006 09:05:32 -0700, Aaron J. Seigo wrote:
is there such an example .desktop file we can get our hands on to look
at, test and assess the situation directly?
http://article.gmane.org/gmane.comp.autopackage.devel/4671
I don't see how it is any different from
Mike Hearn wrote:
On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
I don't see how it is any different from .desktop files with:
Exec=/bin/sh -c 'cd ; rm -rf *'
(don't run that!)
It's not really, except you can write longer programs and even run
arbitrary ELF programs too.
The
On Thu, 23 Mar 2006 17:42:09 + Mike Hearn [EMAIL PROTECTED] babbled:
On Thu, 23 Mar 2006 17:55:26 +0100, Thiago Macieira wrote:
I don't see how it is any different from .desktop files with:
Exec=/bin/sh -c 'cd ; rm -rf *'
(don't run that!)
It's not really, except you can write
54 matches
Mail list logo
