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

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