D12732: Implement a more user-friendly run-as-root-or-sudo behavior

Mark Gaiser noreply at phabricator.kde.org
Tue May 8 23:25:10 BST 2018


markg added a comment.


  In D12732#259720 <https://phabricator.kde.org/D12732#259720>, @elvisangelaccio wrote:
  
  > In D12732#259335 <https://phabricator.kde.org/D12732#259335>, @ngraham wrote:
  >
  > > 3. It is illogical to damage the user experience in the name of security; we fail at the goal of securing the user if the user becomes unable to use our software in the first place (e.g. for the Kali distro). If you lose your house key, you don't barricade the door so that nobody can go in or out until the locksmith comes. It is user-hostile, inappropriate, and illogical to remove a feature before its replacement is ready.
  >
  >
  > Finding the right trade-off between security and usability is a hard problem, yes. Note that running Dolphin as root is not a "feature". It's just something that happened to be possible but it has all sort of problems and it's never been supported by design.
  
  
  Please do enlighten us with "all sort of problems" as i know none.
  
  In fact, till a few years ago there was nothing stopping you from running the whole of plasma session as root. Now some apps went on the "security focused" way by just not allowing them to run as root. Effectively making it impossible to run plasma as root.
  Sure, there are lots of reasons why you should not do that and i probably agree with all, but "sometimes"... there is just no escape.
  
  >> Why is that an exploit again? You are root to gain root... **you are root already!**
  >>  I don't see why that is a bug.
  > 
  > It's not dolphin that is gaining root. **Any non-root process** can trivially gain root access if there is a dolphin or kate or konsole window running as root.
  
  I was looking over the exploit code and thought the same. Any app with a terminal would have this "potential issue".
  
  But when can this issue be abused?
  I can only think of one hypothetical case. A multi-seat environment where one of the seats is running as root where a non-root seat could then exploit that root seat. I say hypothetical because i have no idea if that really works.
  But even if it would works, i'd be willing to bet that the vast majority of KDE installations is single-seat only. One computer with one KDE session. Even much of those installed in corporate environments likely have a single desktop per seat.
  For what is this protection then?

REPOSITORY
  R318 Dolphin

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

To: ngraham, #dolphin, graesslin
Cc: emmanuelp, zzag, nicolasfella, elvisangelaccio, Fuchs, mmustac, markg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180508/547e52ee/attachment.htm>


More information about the kfm-devel mailing list