use sudoedit in Whonix documentation and Whonix software

The wiki tells users to edit files as root using mousepad or kwrite. These are both GUI programs which should not be run as root. GUI applications often contain many security holes and running something like that as root is something you don’t want to do.

Running any editor as root is also insecure.

I recommend to change it to tell users to use sudoedit which copies the file to a temporary location, edits it as a normal user and then overwrites the original using sudo.

This way is much more secure as it doesn’t run the editor part as root.

The editor used with sudoedit can easily be configured with the SUDO_EDITOR variable.

E.g. SUDO_EDITOR=nano sudoedit /path/to/file

2 Likes

This might be too contagious and specialized, therefore split off from Long Wiki Edits Thread - #1528 to its own dedicated forum thread.

1 Like

Can also GUI editors such as mousepad be used to sudoedit files?

1 Like

Yes, they work fine.

1 Like

How to use mousepad with sudoedit?

1 Like

Run SUDO_EDITOR=mousepad sudoedit /path/to/file

The SUDO_EDITOR variable can also be set globally in /etc/environment and it can be used with just sudoedit /path/to/file.

1 Like

Interesting for editing configuration files etc, however as a general approach, I am not sure. I don’t like applications that copy files to temporary locations - when the content is sensitive I want to (at some point) be able to wipe it with shred. The temporary copy probably gets deleted less securely.

This is outside the threat model since what you mentioned is not the only non-amnesic issue anyhow, as per:

Whonix ™ is not Amnesic:
Whonix and Tor Limitations

Is there a Whonix ™ Amnesic Feature / Live CD / Live DVD? What about Forensics?:
Technical Introduction

As per above link there might be a Live DVD / USB in future but when that exists, above

Point taken. Personally for confidential / valuable content that I expressely generate though (not logs or anything done by the system) I feel better when it’s wiped with shred, coupled with periodically wiping all available free space on the host. Needless to say, the HD isn’t SSD.

Let’s take a crypto wallet, for example, electrum. The wallet keys are stored on the HD. If the user specifies a password, they are stored in encrypted form. Now say they were stored unecrypted on a temporary file, which was then deleted and the encrypted file written. I think that would be an unwanted behavior.

Now why would they do something strange like that, I don’t know, but it can happen that sometimes I store self generated private keys on the HD, then I encrypt the file with gpg and shred the original. Sometime I need to import the keys to another wallet. If I edit the original, I certainly don’t want it to be copied anywhere.

All that is probably not relevant for configuration files discussed on the wiki. The closest I can think of is the private key of an onion site, I don’t know, I will feel better not have a file with that info copied anywhere even temporarily. But I would probably use nano to edit it rather than any GUI editor.

By default it copies them to /var/tmp. If you want, you could mount this directory as a tmpfs which would store all copies in RAM so they will never even touch your drive. This might break some things though as /var/tmp is meant to be persistent.

I’m not sure if it’s possible to make sudoedit use a different directory like /tmp which is mounted as a tmpfs by default.

1 Like

Even if sudoedit was bad for “partial anti-forensics” it would still
have lower priority than “use sudoedit for better security” since there
will be a “not-only-partial” Live version of Whonix most likely in future.

1 Like

That’s good. That’s something that users can if they want to change defaults.

For Whonix distribution default environment variable we should probably use one of the mechanisms discussed in this post Hardened Malloc - Hardened Memory Allocator - #12 by Patrick (and below) to set SUDO_EDITOR. Env var set to GUI editor should only be done in X (because wouldn’t work for CLI version).

Should probably go for this. Help welcome implementing this.

Package, probably GitHub - Kicksecure/usability-misc: Misc usability improvements looks like a good fit?

1 Like

Sounds good. I’ll create a pull request.

2 Likes

How does this look?

2 Likes

Nice! Merged. Added a few commits on top.

1 Like

Also, since sudoedit copies the file to another location before editing it, the editor will say that you are editing a different file. Usually it will say /var/tmp/(filename).(random letters). This may be confusing to some people so it’d probably be a good idea to document this somewhere.

1 Like

There is the point regarding filename and location change, resulting in wrong syntax highlighting, as described in

Since the files are copied to temporary files, the filename and location, which are often identifying characteristics for filetype detection, are lost. So, where /etc/apache2/apache2.conf would load syntax highlighting suitable for Apache2 configuration files ( set ft returns filetype=apache ), /var/tmp/apache2XXcLFdTD.conf has filetype=conf .

I didn’t observe this issue with mousepad though.

1 Like

You edit it, then shred it? I think you already have issues right there. Say you have a long file, and you remove part of it when you edit, and at some point in the future shred it. Which part gets shredded? if I understand correctly, only the data at the last version of the file.

This is now documented.


Hardcoding mousepad in https://github.com/Whonix/usability-misc/blob/master/usr/lib/default-editor/default_editor.sh is not great. But there is no /etc/alternatives/x-editor or visual.

Debian feature request: please provide /usr/bin/visual
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758228

1 Like