use sudoedit in Whonix documentation and Whonix software

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

https://github.com/Whonix/usability-misc/blob/master/usr/lib/default-editor/default_editor.sh

1 Like

gksu Removed From Ubuntu, Here's What You Can Use Instead suggests to use gvfs. Example:

gedit admin:///etc/default/apport

Bug #1740618 “Remove gksu from Ubuntu” : Bugs : umit package : Ubuntu saying

Debian has removed gksu. I recommend that we remove gksu and libgksu for Ubuntu 18.04 LTS also.

It is recommended that developers use PolicyKit to only use elevated privileges for the specific actions where it is needed.

It is recommended that users use the gvfs admin backend available in Ubuntu 17.10 and 18.04 LTS. You can do this with the admin:// prefix. For instance, instead of running gksu gedit or gksu nautilus to edit /etc/default/grub, navigate to admin:///etc/default/ and open the grub file.

Ubuntu 17.10’s default session (a themed GNOME on Wayland) does not support gksu. Ubuntu 18.04 switched back to using X instead of Wayland as default but it is expected that Wayland will once again be the default in 18.10.

policykit? gvfs?

Citation from more authoritative sources may be required to learn what the plan for Debian is.

That is because RootSudo - Community Help Wiki contradicts it and says

gksu has been replaced by pkexec, but even pkexec is being deprecated by the mainline Ubuntu developers. They have taken the position that file manipulation and editing under root should be restricted to the command line.

Also citation required.

1 Like

Very much citation required since RootSudo - Community Help Wiki also says:

March 14, 2019 PLEASE NOTE: This wiki article is being significanly rewritten as it contains a good deal of old, dated and possibly questionable material. Using caution and consulting with others on the Ubuntu Forums or Ask Ubuntu is highly recommended!

New bug I ran into: GUI editing of whonix firewall no longer opens/responds

1 Like

I.e. Try run this manually on command line:

/usr/lib/whonix-firewall/firewall50user
bash -x /usr/lib/whonix-firewall/firewall50user
sudoedit /etc/whonix_firewall.d/50_user.conf
ls -la /etc/whonix_firewall.d/50_user.conf
cat /etc/whonix_firewall.d/50_user.conf

env | grep -i VISUAL

expected output:

VISUAL=mousepad

The VISUAL environment variable influences whether sudoedit will work in GUI or not.

The first three commands open mousepad,

env | grep -i VISUAL

gives the expected out put but the link in the whisker menu doesn;t respond at all.

1 Like