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.
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.
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?
Sounds good. I’ll create a pull request.
How does this look?
Nice! Merged. Added a few commits on top.
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.
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
returnsfiletype=apache
),/var/tmp/apache2XXcLFdTD.conf
hasfiletype=conf
.
I didn’t observe this issue with mousepad though.
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
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.
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
- whonix-firewall/usr/share/applications/whonix-firewall50user.desktop at master · Whonix/whonix-firewall · GitHub
- https://github.com/Whonix/whonix-firewall/blob/master/usr/lib/whonix-firewall/firewall50user
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.