Re: Trusting .desktop files

2017-02-11 Thread Sebastian Kügler
On Saturday, February 11, 2017 7:24:11 AM UTC Martin Gräßlin wrote:
> What I don't like in general is that this is all happening as $user.
> Thus any malicious program running as $user can also just change the
> list of trusted Exec= values.
> 
> So my suggestion is: let's use polkit.
> 
> The list of trusted .desktop files must be root owned and per user.
> Everytime a user asks for executing a not known (or changed) desktop
> file, it goes through polkit. To detect changes of the desktop file I
> would suggest to store the shasum of the desktop file in addition. This
> would prevent malicious programs to just change the desktop file.
> 
> What do you think? Sensible? Too much?

I like the approach, though it does sound a bit like overkill. But then, going 
the extra mile to improve security is right within our mission, so I think the 
approach is feasible, as it provides a lot of value for what we regard as our 
core competence.

I can imagine this mechanism to be useful for other things as well, such as 
scripts, binaries and such that are user-writable.
-- 
sebas

http://www.kde.org • http://vizZzion.org


Re: Trusting .desktop files

2017-02-10 Thread Martin Gräßlin

Am 2017-02-10 19:56, schrieb Fabian Vogt:

Hi,

The reddit post "How to easily trick $FILE_MANAGER users to execute
arbitrary code"
(https://www.reddit.com/r/linux/comments/5r6va0) spawned a discussion
about .desktop files.


Thanks for bringing up this important topic! (Although I get more and 
more annoyed how bug reporting moves to reddit :-P)



What I'm proposing instead is to keep a list of trusted Exec= values
and ask the user for confirmation
everytime a .desktop file with an unknown Exec= gets opened. 
Advantages:


- (Minor, does not usually happen) Changing Exec= revokes the 
trustedness.

- Copying .desktop files just works. Currently DnD'd .desktop files
from /usr/share/applications/
  onto the desktop are untrusted by default.
- The prompt shown when opening an untrusted file specifically shows
only the Exec= value.
  So it's also the Exec= value the user trusts and not the .desktop 
file.

- Cannot be faked by archives.

As Exec= can also contain relative paths, the working directory needs
to be accounted for as well.

Thoughts, suggestions?


What I don't like in general is that this is all happening as $user. 
Thus any malicious program running as $user can also just change the 
list of trusted Exec= values.


So my suggestion is: let's use polkit.

The list of trusted .desktop files must be root owned and per user. 
Everytime a user asks for executing a not known (or changed) desktop 
file, it goes through polkit. To detect changes of the desktop file I 
would suggest to store the shasum of the desktop file in addition. This 
would prevent malicious programs to just change the desktop file.


What do you think? Sensible? Too much?

Cheers
Martin


Trusting .desktop files

2017-02-10 Thread Fabian Vogt
Hi,

The reddit post "How to easily trick $FILE_MANAGER users to execute arbitrary 
code"
(https://www.reddit.com/r/linux/comments/5r6va0) spawned a discussion about 
.desktop files.

This is normally just a minor security issue as it requires manual user 
interaction. However,
Plasma's ineffective countermeasures give the user a false sense of security 
and that's the main
reason why I think it needs to be fixed correctly.

Dolphin is not affected by the issue in most directories, as .desktop files are 
shown with their
extension by default. Plasma's desktop folder is, however, and so extraced 
.desktop files from
archives for instance can look exactly the same as a text file (icon) called 
README (Name property).

This got fixed with
771e57f3b2c19f4e6f867c01c2457ec87531b4cf '[Folder View] show script execution 
prompt when clicking item'
but that in turn caused every application shortcut on the desktop to open a 
confirmation box first,
for untrusted .desktop files even two! ("Open/Execute?" and "Do you trust 
this?")

kbroulik worked around this by disabling the prompt for files in the desktop:/ 
location:
https://phabricator.kde.org/D4534

However, that basically reverts the fix and the security issue is there again, 
as the marker for
trusted .desktop files (as defined by KDesktopFile::isAuthorizedDesktopFile) is 
the executable bit.
That can be faked easily and is thus totally useless. .desktop files are not 
executable by themselves
as they have no shebang, thus it's also wrong.

What I'm proposing instead is to keep a list of trusted Exec= values and ask 
the user for confirmation
everytime a .desktop file with an unknown Exec= gets opened. Advantages:

- (Minor, does not usually happen) Changing Exec= revokes the trustedness.
- Copying .desktop files just works. Currently DnD'd .desktop files from 
/usr/share/applications/
  onto the desktop are untrusted by default. 
- The prompt shown when opening an untrusted file specifically shows only the 
Exec= value.
  So it's also the Exec= value the user trusts and not the .desktop file.
- Cannot be faked by archives.

As Exec= can also contain relative paths, the working directory needs to be 
accounted for as well.

Thoughts, suggestions?

Cheers,
Fabian