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

[Martin Flöser]

graesslin added a comment.


  In D12795#265657 <https://phabricator.kde.org/D12795#265657>, @ngraham wrote:
  
  > In D12795#265648 <https://phabricator.kde.org/D12795#265648>, @graesslin wrote:
  >
  > > 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>
  >
  >
  > In that patch, your reasoning for prohibiting running KWin as root is that "We cannot guarantee that running KWin as root is secure". <https://phabricator.kde.org/D13008>
  >
  > In the discussion here, you said of other software (including our own) that "new vulnerabilities are discovered each and every day" <https://phabricator.kde.org/D12795#265648>. That means we can't guarantee security anywhere else either.
  >
  > Ergo, by your reasoning, we should prohibit running all software because we can't guarantee that it's secure.
  
  
  Erm no. In this and the other software it's about running software as root while at the same time other software is running as a less privileged user. What KWin cannot guarantee is that it is secure if it is running as root and other applications are running as less privileged users. KWin as the windowing system is connected through a socket with applications running on the same or different host. KWin was developed as an X11 window manager with the situation that the X server was running as root while the window manager (KWin) was running as a less privileged user and all other applications are running as the same user. Attacking KWin didn't make any sense. You couldn't gain more privileges compared to what the application already has. The thing to attack was the X Server.
  
  Now with Wayland the situation changes. KWin moves into the place the X Server used to be. If KWin runs with higher privileges than other applications it is an attack target. But KWin was not developed for such a situation. Thus it cannot guarantee that this is secure for this usecase. Especially as it loads toolkits which don't guarantee this (most crashes in KWin are after all in libGL).
  
  What's important is to evaluate the threat level of an application. KWin_Wayland has a very low threat level. It runs as the same user as all other software in the session. Trying to attack KWin doesn't gain you anything. On the other hand if we have sandboxed applications attacking KWin becomes interesting again. Then the windowing system would be a way to get more privileges than the application currently has. That is something we haven't protected yet. We could say KWin needs to take care of it, or that the sandbox needs to take care of it.
  
  In the case of random applications the threat level is quite different. Let's take gwenview. The threat level of gwenview are the image formats it loads and parses. A malicious drafted image could abuse gwenview to get code executed. That is a threat level KWin doesn't have.
  
  So in summary it's always important to look at the threat level and how to protect or mitigate against it.

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/20180521/bd87f112/attachment.htm>