Dom0 Code Editor/Doc Viewer Without Security Risks?

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


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 ?