Posted on by Martin Flöser

Editing files as root

For years I have told people to not start Kate as root to edit files. The normal response I got was “but I have to edit this file”. The problem with starting GUI applications as root is that X11 is extremely insecure and it’s considerable easy for another application to attack this.

An application like Kate depends on libraries such as Qt. Qt itself disallows running as an setuid-app:

Qt is not an appropriate solution for setuid programs due to its large attack surface.

If Qt is not an appropriate solution for command line arguments running as root, it’s also not an appropriate solution for running GUI applications. And Qt is just one of the dependencies of graphical applications. There is obviously also xcb, Xlib, OpenGL, xkbcommon, etc. etc.

So how can another application attack an application running as root? A year ago I implemented a simple proof of concept attack against Dolphin. The attack is waiting for dolphin getting started as root. As soon as it starts, it uses the XTest extension to fake input, enable the embedded konsole window and type into it.

This is just one example. The elephant in the room is string handling, though. Every X11 window has many window properties and every process can write to it. We just have to accept that string handling is complex and can easily trigger a crash.

Luckily there is no need for editing a file to run the editor as root. There is a neat tool called sudoedit. That does the magic of starting the editor as the user and takes care of storing the file as root when you save.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.

Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

I am also aware that if you run an application which is malicious you are already owned. I think that we should protect nevertheless.

64 Replies to “Editing files as root”

  1. I think this is a good change although to be honest was already using ‘ sudo -e’ with nano/rvim for editing system files so not much change for me.

    1. Could you tell me what the difference is between plain “sudo” and “sudo -e”? I’ve been editing text files using “sudo nano file.txt”, so I’ve avoided the problem described here by Martin. I’ve looked at the sudo man page, but the juicy stuff about NOT about restrictions or temporary files is incomprehensible to me.

        1. what aabout
          cp file in /tmp
          edit with kate
          save after from bash using echo PASSWORD | sudo -S mv fileintemp fileinrootlocation
          ?
          is it stupid ?

          1. That is pretty much what sudoedit does.

            I would recommend against echo password as that saves your password in bash history.

  2. I feel like `sudoedit` is still the wrong answer (although one which currently works).
    In the long term I’d like to see this handled by KIO + PolicyKit or similar mechanisms.

    This would allow to handle these kind of things transparently from within the editor, so I wouldn’t have to do something “weird” to edit a file as root – I can open/edit a file as long as I can prove I have privileges to read/write this file as root (or any other user which is required to access the targeted file).

    This would even allow to transparently browse through the filesystem in the filedialog by simply asking for the required permissions through KIO once the current user permissions aren’t sufficient anymore.

    1. This reminds me, GNOME has recently added an ‘admin’ gvfs backend which in theory would allow doing exactly that. (E.g. if you try to open ‘admin:///etc/passwd’ you get a polkit prompt.) I’m sure the same would be possible to implement in KDE as a kioslave or similar.

    2. I also think this is the right way.
      sudoedit feels like workaround instead of solution.

      KDE guys should sometimes try to use eg. Windows or MacOS and check how some of those things were solved there, maybe there is no need to invent the wheal.

      Also there is very annoying use case: when you edit file to with you don’t have permissions (not necessary system files) and when you finish, and you try to save it you are getting message that you cannot do that and have to redo everything again.
      This is I guess general issue with linux (not only KDE) because the same behavior is in eg. vim or other editors.

      Regards

      1. You don’t have to “redo everything again” in that situation. From that same editor you just save to a writable place, and then you just need to move that file over the other one.

  3. It’s a good direction, but do fails for the users that don’t want to jump through hoops to edit a file. Especially those that wouldn’t even know what a terminal window is if it screamed at them.

    The right thing would be to let the user just edit any write protected file in memory as usual. As soon as the user wants to save and Kate realizes that it cannot write to the file in question, a policykit elevation prompt should show up which tells the user that in order to save this particular file, higher privileges are required.

    It would put a stop to having to educate people how to edit root files in a graphical session. Why has nobody thought of implementing that?

    1. What you say it’s correct and matches what Elias wrote.

      The change I did is still needed. Even if the editor can use polkit to save the file, we should not allow running a GUI app as root.

      1. Editor indeed should not run as root, but that part should be cut out when proper solution is available, not before.

    2. If someone doesn’t even know what a terminal window is, why are they messing with root-owned files?

      As for the polkit suggestion, many people “thought” of implementing that but the thought didn’t magically materialize into working code. Maybe you could send the patch 🙂

      1. This is the wrong userflow. Many times a user is told…by the OS or a well-minded forum member or G+ or a friend or whoever – that dropping to a terminal is “the Linux way” no matter what. At the same time, they have legitimate user-only arguments for needing to do things as root. Like saving a txt file in a non-user directory. Or trying to edit a config file that has otherwise borked their system. The real answer, from a user’s perspective, is to be able (out of the box) to edit a txt file as root in a Linux distribution without having to drop to a terminal or compromising their system. There’s a legitimate user-case reason why root-actions-servicemenu is (was) the #1 downloaded Dolphin extension. When envoking this in KDE, they are usually going to open in Kate or KWrite.

    3. > a policykit elevation prompt should show up which tells the user that in order to save this particular file, higher privileges are required

      Exactly. Especially as nothing is more frustrating than forgetting that you need to edit file as root, editting it as user and getting the error that you cannot write to it after pressing Ctrl+S.

  4. All this will accomplish is that people will switch to using a GUI editor the *can* start as root.

    I understand your reasoning, but this is the wrong way to go about it.

  5. Perhaps you edit a few files as root, but people who need to edit a lot… won’t be using sudoedit, they will use gedit or similar, and will stop using Kate. At least give them KDE options.

    1. Yes and no. Kdesudo is not running as root, so that is fine. The application launched through kdesudo runs as root, so exposed the same issues.

  8. “Starting GUI applications as root is extremely insecure”
    It’s only extremely insecure if you already have malware running on your system, which is, as everyone already knows, extremely insecure.

    Meanwhile: don’t hinder people’s lives, people who care about security don’t have malware, and shouldn’t be “awarded” with worse command-line editors when KDE software is better.

    1. And command line editors are not any more secure if I understand reasoning here. They will be run in let’s say Konsole which is a GUI app, so some rogue/malware (as in Martin’s demonstration with Dolphin) can still use text editor to edit random file as root.

      Even if we use sudoedit and our text editor is started as unprivileged user *from terminal*, malware can close the editor on X11 and quickly type sudo -s. And if people need to start sudoedit I’m sure most of them will be doing it via command line… So aren’t they still vulnerable?

      1. No, your scenario does not work reliable. Especially not if sudo is configured to not cache the password.

  10. What if I need to run gparted? It’s not possible to run it without root. But when I run it with sudo it’s ugly.

    2. No, it is not. And neither is KDE Partition Manager. They looks ugly because sudo eats environmental variables. Well, at least I fixed KPM looks when started with kdesudo. It now declares required shell variables.

      As for root. I briefly looked at possibilities to run KDE Partition Manager as non-root. This is hard… Many times harder than the adding polkit support to KIO as mentioned in other comments here. And even that is not done yet or we wouldn’t be having discussion on this post…

      1. So what’s the solution for using KDE Partition Manager? When I start it directly it asks me for password (KDE su) but doesn’t accept it. I have to launch it again with ‘kdesudo partitionmanager’ and the password is accepted.

        1. I think in your case it’s the matter of updating it. I suspect you are running an ancient version. Ideally you want to run version 3.0.1

          As for the kauth/polkit support, well any help from those who know it well would be appreciated. After some initial work on it we ran into some issues that we were not able to solve :(.

          1. Thanks for reply. The version is 3.0.0, KDE Frameworks 5.28.0, Debian Stretch. I’m glad it works anyway. And thanks for developing it, support for encryption/LUKS is great.

              1. On Debian you have a choice to disable a root account, which I did. So I’m not a root but I have administrative privileges and it is always sufficient to type my user password whenever I perform administrative tasks e.g. upgrading system, changing file permissions/content etc. The only exception is Partition Manager, maybe because it is started normally with ‘kdesu’ and not ‘kdesudo’. Only when I run it with ‘kdesudo’ my password is accepted.

                Now, when I think about it, it’s not really a problem with Partition Manager; when I invoke ‘su’ it doesn’t accept my password either.
                So the only problem is that PM is started with ‘kdesu’ and not ‘kdesudo’ because ‘kdesu’ doesn’t accept an ordinary user password (even if he has administrative privileges) – it accepts only root password.

  13. @martin wouldnt it be much better to finally make a change to the frameworks itself and just ask for more permissions via polkit while saving a file?

    I mean we can just start kate, open /etc/fstab, edit and write in new things, now press save and THEN it’ll “this file belongs to user root, please tell us his password or GTFO”?

    Its just the same with dolphin. There are so many users who just “sudo dolphin” every day because then they can change everything. Its not bad to do this but WHY isnt normal-users-dolphin asking for the root passwd when i want to delete something that belongs to root?

    ? really frustrating things ….
    Teach a user how to use sudoedit or whatever is also not the solution. Integrate polkit into the framework and actually use it when needed (partitionmanager,filemanagers,pkgmanagers,editors) and disable “start as root” for all apps made by KDE, would be the right thing.

    1. Thats a good idea makes it simple and follows the security principal. Also wouldn’t need kde-servicemenu-rootactions any more.

  14. Boy this is a stupid idea if I ever saw one. Use any of the other much better solutions already suggested in the comments.

  15. I find this absolutely unacceptable, and hope distributions will patch this nonsense out. kdesu kwrite is a very common operation (I do it regularly), and blindly refusing to run as root also breaks running the application in root sessions. And people will just use something else, just as Krusader’s easily accessible root mode, or a non-KDE editor.

    1. > find this absolutely unacceptable, and hope distributions will patch this nonsense out.

      As a fellow distributor, I would say the place for these discussions is distributions@kde.org (the mailing list).

      Not this blog, and not even with this tone that does not accomplish anything.

    2. As I recently wrote in another topic about your “patching out upstream changes”: go fuck yourself. I would highly appreciate to never see you comment on my blog again. I find your approach as a distribution person, absolutely unacceptable. Also I would appreciate if you don’t comment anywhere on changes I do.

      You have no idea about the changes down – as demonstrated in the xkbcommon case. You are not even willing to try to understand changes. And you are highly aggressive towards your upstream developers.

      Stop that mess.

  16. Run:
    VISUAL=kate sudoedit

    Or create alias in bashrc:
    alias sudoedit=”VISUAL=kate sudoedit”

    Your favorite editor without root.

    Martin is happy. Everyone is happy

    1. btw. that’s what kate says now when run as root. It gives the instruction on how to do the same with sudoedit. Though we use SUDO_EDITOR instead of VISUAL env variable.

  17. The problem, as commented above, is also related to Dolphin – you need to be root to change folder permission and in KDE 5 Dolphin and System Settings stopped working properly as root. Policy Kit would elegantly solve this problem. Thanks

  18. The other problem with root is inherent in Neon and Kubuntu – whereby, depending on the webside somone lands on, there is too many potential answers…even dropping to terminal. Does someone use “su” or “sudo” or “kdesu” or “kdesudo” or “gedit” or… “oh wait what version of debian / ubuntu are you running. Oh and what? That didn’t work? OK what DE? Ahhh there’s the problem, you’re running the wrong DE for that answer!”. Meanwhile…back at the ranch…

  19. The sudoedit workflow you suggest to use is still a lot less user-friendly than kdesu kwrite. You have to start the editor from the command line for each file, whereas you can open as many files as you want from kdesu kwrite, or even at the same time with kdesu kate. The kdesu version can also be made into a menu entry if it is needed often. Using sudoedit forces you to use the command line.

  20. Yes, Kevin. Also, I see that if you already have Kate opened, then you get an error when executing `SUDO_EDITOR=kate sudoedit FILE`:

    The file `/var/tmp/FILE.XXBO8KAN` was deleted by another program.

  21. I have to agree with the majority of comments here – this is the convoluted way to go.

    In my view, the fact that you may sometimes open a file, finish editing it and then, upon saving, get a “you don’t have permission to edit the file” notification is too much already (not user-friendly, highly annoying).
    And I do realize the hazards of running as root, however, what can I do when I have a tendency to forget what mode am I running from time to time.

    So in my case it’s not about user education, it’s about user-comfortability, which under the current situation (or the proposed one for that matter) is seriously lacking…

  22. For me it has to be: “Security fist usability second.”
    And thank you Martin.
    You changed my workflow already.

    It is not so hard to do a ‘sudoedit [file]’.

    1. A simple App witch does a file dialog and than a sudoedit [file] for all konsole-non-responders would be nice for usability.

  23. If you really insist on “educating” the users with such a dialog, at least make it a warning that can be clicked away with a “Don’t show this again” checkbox, not a fatal error. In the end, it needs to be the user’s choice whether they want to follow your recommended “secure” workflow or not.

  24. I hope this change isn’t just blindly accepted due to your name in the KDE community. I also hope this crusade against stopping users using kdesu does not go any further as it is useful for many applications. People use their computers to primariy get stuff done rather than fart about on a command line out of a misplaced worry about non-existent theoretical attacks from malware which most sensible computer users just are not affected by.

    On the general topic, the greater threat is not root access, rather rogue applications having access to all a user’s personal data as that user. That requires an entire new architecture to fix, not simply getting in a user’s way like these temporary fixes. Therefore, you might as well not turn on your computer at all since your private data is vulnerable since you are using all those horrible unintuitive gui apps /sarcasm

  25. To ask users to adjust their used command line is one thing, but as far as I see this, the sudoedit only works if the Kate session is closed first. This is not a simple change in using a new command line, this requires a complete change in how I (and with me many others) use Kate . It stays open during all work, work on many open files is done as a day continues. This has to stop now too?

  26. What if I am using Dolphin in super-user mode and click on a text file to edit? This would mean I would then have to inconveniently open the command line and then type a cumbersome command just to edit the file.

    And please don’t tell me not to use Dolphin in super user mode as I have seen you tell people in presentations — it is often highly convenient, and the command line is just not friendly for many users. Your theoretical attack vector is not found in the wild and it is highly unlikely that malware is on my machine. If I want to take the “risk” please let me do it. I hope KDE developers have the sense to reject this change.

  27. Pingback: Dateien/Ordner in Nautilus aka Files mit Root-Rechten bearbeiten › Linux und Ich

Comments are closed.