Is there a "VirtualBoxTools.run" equivalent for Qubes?

When I’ve used VirtualBox, with any Linux OS in a box I can run VirtualBoxTools and then I can copy and paste and the VirtualBoxOS has certain features.

Is there an equivalent of that on Qubes for non-Windows Standalone VMs? There really should be!

VirtualBox sucks because the USB Guest Additions are closed source and it wouldn’t surprise me if there were back doors within the GuestTools. (They recently added a notification bar that shows an error when it isn’t installed probably to get more people to install the closed source add on, which may or may not have a backdoor.)

And VirtualBox sucks because it’s not that secure. One breach of the non-Boxed OS using a day-1 exploit and an attacker is in. You can be protected from what’s in the box, but not what’s outside the box.

And VirtualBox sucks because complex routing becomes much harder using it while Qubes makes complex network connections easy once you understand how Qubes works.

I would like to be able to run more Linux OSes installed from ISOs in Standalone VMs. I like being able to see a full contained Linux OS that has a graphical desktop. I hope one day somone creates something and puts in in github so that cutting and pasting into these Qubes becomes easier.

Also, you can move files into a Standalone Linxux VM using a USB drive. You attach the USB drive to one Qube, move the files into the USB, then attach it to the Standalone VM. If that can be done, why can’t I just copy something into it using dom0? Why do I need that extra piece of physical hardware? Or am I doing things wrong?

1 Like

Only faster USB versions a proprietary. aren’t they?

Well, isolation by VirtualBox is also not that good as Xen has.

You can copy files with qvm-copy and qvm-copy-to-vm tools, but some Qubes OS packages should be install inside the VM (qube) to receive files. If you cannot install these tools you can mount some shared storage, the same way you would do with separate computers (USB drive will also allow you to more files between those).

Well, in theory dom0 has full access to LVM pools (disks and partitions) of any qube, so it is possible to simply put files inside any qube with any operation system (at least whilst it is turned off) but it will involve dom0 into activities of parsing, reading and writing to filesystem (that can be modified by qube iself), so it is would not be a secure approach.

1 Like

I came here from VirtualBox running on XUbuntu. I never could bring myself to trust that setup. The host OS is directly exposed to the internet, running an VM Manager that’s closed source. Whereas with Qubes the VM Manager Xen is running directly on the bare metal, and the “host” OS (dom0) isn’t really a host; it’s really just another VM. Yes, that’s not exactly right as a way to characterize the difference but Xen has a much, much smaller attack surface than Xubuntu does, and the code is open source. (So much so that I’m actually able to tinker with things and make them work as I want–though I don’t touch Xen!)

I actually find it easier to move files on Qubes because I don’t have to muck about with mounting and unmounting then mounting again, something to make it visible first to one VM, then another.

2 Likes

There is still not cut and paste inside the Standalone VM and turning the OS off and using qvm-copy-to-vm is time consuming and harder.

You said some Qubes OS packages should be installed. Which Qubes OS packages? What do I need to type in a terminal?

In order to get cut and paste from one VM to another one, for Windows VMs you have to install Qubes Windows Tools (QWT) in them.

For Linux VMs I have not seen such a package, just the recommendation to use one of the templates provided or to create one using the Qubes builder. Could perhaps someone having Linux know-how (@unman ? / @fepitre ?) clarify this?

There is not such a package.
While the needed packages are known, in most (all?) cases the standard
Qubes packages will break an HVM if installed.
As there are stock work rounds based on inter qube networking, and I do not
promote use of HVM with their own desktop, I have not followed up on
this.
If a stand alone is required with functional qvm-tools, create a
stand alone based on a template.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

Thank you for explaining the situation!

There are still scenarios where such a package might make sense. For instance, the Debian-based system Q4OS is provided as a ready-to-install package, coming with its own desktop (Trinity, a very fast earlier version of KDE that can be configured to look just like the Windows desktop). It would be helpful if such a system could be integrated into the Qubes environment by adding the possibility to use inter-VM cut and paste.

So far, I have not found any way to integrate such a system using the Qubes builder, but this may be due just to my rather sketchy Linux knowledge.

The simplest way would be treat it as a flavor of debian.
There’s a script provided to convert off a stock debian, so you could
build debian11+q4os and put the conversion script in
builder-debian/template_debian/q4os and it will get called automatically
as part of the build process.
You can control the name of the final template as you will.

It seems that building a template for Q4OS is not possible, because they do not offer a git repository to download the necessary modules. All that can be downloaded is an ISO with an installer that then builds the system.

Anyhow, this is not quite what I intend: As far as I understand it, there are two ways to install a Linux-based qube:

  • As an HVM, you will get a system that is equivalent to the same system installed on bare hardware, complete with its own desktop manager, but without integration into Qubes, especially without inter-VM cut and paste and without qrexec support.

  • Alternatively, by installing it as a - Qubes- or community-supported or self-built - template, you will get full integration, but this system uses the Qubes desktop manager, e.g. XFCE, ignoring its own desktop manager if one is present.

What I am looking for, is something in between: a Linux-based qube having and using its own desktop manager, but otherwise integrated into Qubes with inter-VM cut and paste and qrexec support. Currently, I see such a configuration only for Windows-based qubes - for Windows 7 even switchable between this mode (“Seamless disabled”) and the standard mode for Linux-based supported qubes (“Seamless enabled”). For these Windows-based qubes, this is accomplished by the Qubes Windows Tools (QWT).

My question is now whether such a configuration could be built also for Linux-based qubes? Especially Q4OS might be interesting in this respect as it allow to mimic a standard Windows installation and so could be used to hide the underlying Qubes system from a casual inspection, like at an airport control.

Am I completely off-track or could this be done, and if yes, with not too much effort? The discussion in Qubes agents with Archlinux HVM (qrexec - gui …) seems to point in this direction, but it is 10 years old, so that I am wondering if it is still revevant.