D12795: Re-allow running Dolphin as the root user (but still not using sudo)

[Martin Flöser]

graesslin added a comment.


  In D12795#265634 <https://phabricator.kde.org/D12795#265634>, @ngraham wrote:
  
  > In D12795#265631 <https://phabricator.kde.org/D12795#265631>, @graesslin wrote:
  >
  > > The ideas of sandbox baloo_file_extractor are after all based on my sandboxing for kscreenlocker.
  >
  >
  > Then could you help review it, at least?
  
  
  Given that it's based on my code I suggest that someone else reviews as there is a chance that if I did a mistake, which got repeated, I wouldn't notice either.
  
  > 
  > 
  > In D12795#265631 <https://phabricator.kde.org/D12795#265631>, @graesslin wrote:
  > 
  >> I never used an exploit. What I would use is the chrome to download behavior. That is not fixed, it's still the default.
  > 
  > 
  > Ah, so the problem is that the user actually //opened// a malicious file. On macOS at least, Finder prompts the user before they can open a file that was auto-downloaded. Perhaps we need to do the same.
  
  It's one of the problems. To explain again: a website can trigger downloads in Chromium. They are by default saved to the user's home directory without (!) asking or informing the user about it. If there is any application running which monitors the directory and loads the files, you have lost.
  
  Examples are:
  
  - baloo indexing
  - dolphin showing previews
  - gwenview showing previews
  - music player picking up new audio files
  - video players picking up new audio files
  - many more
  
  They all act on the new data, because usability suggests to show the new downloaded files. And that's good! But it opens a risk. If there is a vulnerability, the user gets owned. Unfortunately we cannot harden against all, because new vulnerabilities are discovered each and every day. So yes mitigation is unfortunately one of the things we need and have to consider as strategy. What you describe from OSX does not protect against such problems. Unless we change the operating system and get every application to implement the new hooks to save downloaded files.
  
  > 
  > 
  > In D12795#265619 <https://phabricator.kde.org/D12795#265619>, @graesslin wrote:
  > 
  >> baloo is just one example. Every program on the user's system can be abused to it. You can also hope that the user just clicks it. Download a video, which uses a vulnerability in vlc, download a zip file which uses a vulnerability in gzip. There are just so many ways. All you need is a simple bug in an application.
  > 
  > 
  > Sounds like you've just described why security is hard. :) You've also described the proper response to a security threat: doing the hard work to harden apps, not the easy and lazy approach of simply disabling a feature that's potentially vulnerable to them. It's not like we should disable opening videos in VLC or zip files in Ark just because there are security vulnerabilities.
  
  no, hardening does not help. It's part of the picture, but mitigation is as well.
  
  > Since you've said you prefer to stay in the KWin world, ultimately this is the Dolphin maintainers' decision. We've heard lots of arguments on both sides, now I think it's fine for someone with some authority here to make a decision. However I would note that while not a maintainer, I'm someone who's actively involved in Dolphin's development and who submits a lot of patches, so I hope that counts for more than nothing.
  
  Actually I find it an interesting discussion going far further than Dolphin. If we can raise more awareness for security issues through such discussions, that's good. For example it just motivated D13008 <https://phabricator.kde.org/D13008>

REPOSITORY
  R318 Dolphin

REVISION DETAIL
  https://phabricator.kde.org/D12795

To: ngraham, markg, elvisangelaccio, #dolphin
Cc: chinmoyr, cfeck, elvisangelaccio, mmustac, Fuchs, markg, graesslin, nicolasfella, zzag, kfm-devel, emmanuelp, spoorun, navarromorales, isidorov, firef, andrebarros
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180520/0afae54d/attachment.htm>