What code editor/doc viewer do you recommend for Dom0, with the smallest attack vector/security risk, but still has a GUI?
But why?
You can send files from dom0 to VMs if you need to work on them.
I saved some dom0 logs using vim, and sent to vm to post.
I need to have some docs viewable before any of the appVms load.
Best way I can imagine to do that is to have a doc/code viewer/editor in Dom0 that can be trusted.
you could use vi if you can accept the rather old UI (I believe it’s preinstalled), otherwise just install neovim and relevant add-ons. Compared to GUI-editors like VS-Code or Atom a command-line tool like vim would probably be the best solution.
While I also agree that CLI editors like @S9qPsAMNuW4ax5EF5 mentioned (I recommend micro, pretty much works out of the box and has mouse support) are acceptable to be used in dom0, I think doing these opts in dom0 is not the solution, you could create a vm for opening these files only and set it to autostart (while disabling all other vms autostart), that way you can accomplish what you need without compromising security
2 Likes
We have the qvm-open-in-vm tool, but it is not available in dom0. While there is little reason to edit arbitrary files and store them in dom0, it could make sense to open a full-fledged text editor to act on scripts, salt recipes, etc, without necessarily installing more software there. It could also help to use, e.g. a recent emacs, which could even be unavailable in the old fedora that serves as dom0 – and it would even be possible to install a new major mode using its builtin package management, which is definitely not going to happen in dom0.
I guess it is forbidden because precisely it would be a less secure VM feeding potentially harmful stuff into dom0.
But maybe we could mitigate the risk, eg. by letting the user accept or reject the new version by looking at a diff. It would not even need to be restricted to “open in vm”, as the same mechanism would be useful for importing newer versions of a script (that typically live in a git checkout in a qube).
Anyone seeing problems with this idea ?
2 Likes
Don’t kick vim too hard. It may be time to learn it since it pretty much comes standard with most every linux installation. Also it’s standard on the debian, fedora, whonix, and arch vms.
It isn’t too hard to configure for code themes and highlighting. You can use the ‘view’ command as a code/text document viewer.
You can select color schemes such as:
Download it to [user@AppVM] ~/Downloads (AppVM is any network enabeld application VM)
It’s a text file, so copy it to dom0 using:
[user@dom0]~ qvm-run --pass-io AppVM 'cat /home/user/Downloads/solarized.vim' > ~/.vim/colors/solarized.vim (directory .vim/colors will likely have to be created first)
The result should be: ~/.vim/colors/solarized.vim
Then create/edit ~/.vimrc and configure vim to use the color scheme:
vim ~/.vimrc
i (press ‘i’ to enter input mode)
Type:
syntax on
colorscheme solarized
:wq (write and quit vim)
Now when viewing a code file the code should be highlighted using the solarized color scheme.
Once vim is set up with a color scheme it can be used as a read-only colorized code viewer:
view someprogram.py
There are a bazillion color schemes and vim can recognize different code languages.
There are also color schemes that come installed with vim. See directory:
/usr/share/vim/vim82/colors
Any installed color scheme can be used in vim using the
:colorscheme <colorschemefilename>
within vim.
VimSub A color scheme that looks like the default Sublime Text 3 theme
VimAtom A color scheme that looks like the default Atom theme
VimVSCode A color scheme that looks like the default VSCode theme