Rodney Dawes wrote:
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 you have the relevant execute permissions.
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.
It doesn't prevent the .desktop file from having a misleading icon at
all. You're not changing the semantics of what goes in the Icon field.
There is no need to change the specification of the Icon field. As I
said the desktop environment can overlay an emblem that identifies the
file as untrusted which makes it easy to differentiate the undtrusted
.desktop file from whatever type of file it is trying to pass off as. If
an emblem is not enough, the desktop environment could ignore the
.desktop icon entirely for files that don't have the +x permission.
There are two categories of .desktop files:
* those installed by the system, typically as part of KDE, Gnome or
third party software. Those are trusted. They should be able to have any
icon they want with no overlaying emblem. And they should also be able
to run any command they want without pesky warnings.
* and then there is those that got downloaded off the internet or come
from other untrusted sources. Those must not be allowed to execute
without a warning to the user. We also don't want them to be able to
show any icon they want, or we at least want to overlay an emblem of
some sort to avoid confusion.
The one question is: how do we distinguish .desktop files from the first
category from .desktop files from the second category.
Four solutions have been proposed:
1) Define and use an 'Untrusted' Extended Attributes
----------------------------------------------------
Mechanism:
Require that applications actively set this Extended Attribute to
files coming from untrusted sources. Then the desktop environment and
related applications would check for this attribute and treat such files
appropriately.
Pros/Cons:
* Requires a modification of the browser, email clients, etc to put
this attribute on downloaded files.
* A mount option could automatically add this extended attribute to
all files coming from other untrusted sources like usb keys, floppy
disks, etc.
* Extended attributes are fragile in that tar does not preserve them
(currently), many file systems don't support them, etc.
* Requires further modifications to tools like tar so files
extracted from untrusted archives 'inherit' the untrusted attribute,
unless a special command line option is specified. Same thing for cp,
mv, etc.
* This is independent from the traditional permission bits and thus
can be used for any type of file, including office documents or whatever
presents the slightest risk.
* Probably hard to manage.
* Might be a long term solution but it will take years to put in place.
2) Use the +x permission bit
----------------------------
Mechanism:
In this scheme .desktop files that are missing the +x bit are
considered untrusted. This relies on the fact that downloaded .desktop
files don't have the +x bit set and can thus be treated in a special way.
Pros/Cons:
* Requires no modification of browsers, email clients, etc since
they should already not be putting the +x permission on downloaded files.
* Requires modifications to the desktop environments and file
managers so they check the +x bit on .desktop files and take appropriate
action.
* Requires modifications to the packages shipping .desktop files so
they have the +x execute bit. Fortunately there is no technical obstacle
to that.
* Mount options make it possible to decide whether material stored
on a filesystem that does not support Unix permissions will be treated
as trusted or not. This takes care of USB keys, floppies, Windows
partitions, etc.
* Makes sense independently of any security consideration because
.desktop files are equivalent to shell scripts: they are text files
whose primary purpose is to start applications and that can run
arbitrary commands. As an added bonus, if they start with
'#!/usr/bin/xdg-open' they can also be run from the command line.
* An attacker could ship the .desktop file in an archive so that
extracting that archive would create a .desktop file with the +x
permission set. The same scenario can happen with shell scripts and ELF
binaries too, except that the .desktop file would be displayed with
whatever icon it wants. This scenario still requires an extra step
before the user can run the .desktop file, rather than just an
accidental click.
3) Add a cookie
---------------
Mechanism:
Add a Cookie field to .desktop files. This field would contain a
hard to predict value specific to the computer or user, for instance the
hexadecimal representation of a random 128bit number. At least one
cookie is needed. That cookie would would be generated when installing
the OS, would be stored in /etc/xdg-cookie for instance. Only .desktop
files containing this cookie would be trusted.
This mechanism relies on the fact that the attacker cannot predict
the value of the cookie so that his .desktop files would either be
missing that field, or have the wrong value, thus identifying them as
untrusted.
A variant would add a secondary per-user cookie to protect the
system's users from each other. Note that this requires that the system
cookie be only considered valid for .desktop files that belong to root
and that the secondary cookie only be considered valid if the .desktop
file belongs to the user.
Pros/Cons:
* Makes it impossible to ship prebuilt .desktop files in software
packages such as Debian or RPM. All .desktop files would have to be
modified at install time which is a significant change from the current
situation. Such files would also be reported as different from the copy
that shipped in the RPM/Debian packages. That would make tools such as
debsums and rpm --verify much less useful.
* Makes it impossible to put /usr/share on an NFS filesystem and
share it for multiple systems unless those systems all use the same cookie.
* Works on any filesystem.
4) Sign the .desktop files
--------------------------
Mechanism:
Add a Signature field to .desktop files and use it to store a
cryptographic signature of part or all of the other .desktop file
fields. Since this relies on the attacker not being able to generate a
valid signature for his .desktop file, this requires each computer to
have a unique key.
Pros/Cons:
* Like for cookies, this makes it impossible to ship prebuilt
.desktop files in software packages such as Debian or RPM.
* Like for cookies, this makes it impossible to easily put
/usr/share on an NFS filesystem.
* Works on any filesystem.
* Can also detect modifications to .desktop files though this seems
of limited value.
[...]
Users are going to just get into the habit of always doing chmod
+x, as we have already been doing for perl/python/etc... scripts that
we download off the web.
So you want to tackle the problem of users chmoding scripts they
download from the web too? Good luck!
[...]
I don't mean to write a proposal to change the semantics of Exec. It was
a suggestion as a method for actually solving the real problem, instead
of just sticking our heads in the sand and pretending like the +x bit is
going to make all the problems go away. We need to either actually fix
the problem, or stop overreacting about it.
So you're not proposing to change the semantic of the Exec field after
all. Good because no change to it is going to do anything to solve the
problem.
> A .desktop file that simply
removes all your files is not a realistic attack these days.
You're missing the point which was that simple command can do harm and
that determining whether a command is harmless or not requires
intelligence and knowledge, both of which computers are lacking.
--
Francois Gouget
[EMAIL PROTECTED]
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
