So...does every qube really need a default dvm?

General Discussion
1

As I’ve been regenerating templates (going minimal) it strikes me that unless you go out of your way to make it otherwise, every VM ends up with a disposable VM ready to call up whenever someone sends you a dodgy e-mail attachment or link.

Is there a reason this is done on every qube, even templates? I can think of one; obviously if it’s set for the template, and someone makes an AppVM, the AppVM “inherits” it from the settings on the template.

But is that the only reason? I suspect so but I thought I’d ask the question. And it seems to me not every AppVM needs a default dvm either. Certainly I can’t see why sys-net, sys-firewall, sys-usb, sys-audio, and so forth need a disposable (even less so for their templates).

Am I missing something, or does it make sense for me to set it to “none” except in a few cases (email and browser AppVMs being obvious “you really need this” cases). [An argument can be made that a disposable browser doesn’t need a dvm for bad links or downloads…but even a disposable might have some information an adversary would find useful, even if only a short browsing history.] On the other hand something like Vault shouldn’t need it at all.

So is it just “inertia” (setting it everywhere makes sure it’s there where truly needed) or am I missing an actual global need in any VM for default DVMs?

2

Yes.

As you have an integration with your menu “open in default-dvm”, you get errors. I think it was:
a) easier to design in in a way that every qube has a default-dvm
and
b) it would not make new users be concerned about some error messages if they don’t set it up.

You do you. I don’t think you are wrong, but i just don’t use dvms if i don’t want to so unsetting it is more work for me.

Well, but what for converting pdf or images to trusted ones if you should ever need one? ususally my whonix disps live longer than “only one download”, so this is the more secure way, but i get your point.

There is no need i know of, as you can see it runs also when set to none.

3

To make it clear, I’m not advocating for changing the distro (because the reasons I can see are very good ones for a distribution that will be used by new users); I’m just trying to figure out if I’m making a big mistake in removing them. (Incidentally the way I’ve structured my salt files, it’s easy enough to just set it to none by default, but then, specifically add it when wanted. In fact, I have one default DVM for email (which opens a browser and has a network connection) and another for browser windows (which opens up downloaded things and has no network connection so a phone-home in a bad attachment won’t work). The Email qube, of course also has access to the offline attachment viewer DVM).

As you said “You do you” and I certainly will take that advice :D; I’m just trying to make sure there isn’t some subtle mistake in what I’m doing.

4

Oh no, if you don’t use the disposables, you can totally set them to none or whatever else you choose.

In linux there are some hundred ways to do stuff, in qubes there are thousands. And the correct way usually is very specific to the user, but good idea asking before doing something that could potentially be a security risk. :slight_smile: From my perspective in this case there are no ill effects i can think of.

5

You ain’t kidding! I doubt you’d even recognize my system.

1 Like
6

So…does every qube really need a default dvm?

No. I have many qubes where I choose to set the default disposable template to (none), since I know I won’t ever want to launch a disposable from those qubes, and I haven’t run into any trouble.

1 Like
7

If something is especially set to none when me, it’s the default netVM.

1 Like
8

You just reminded me of a downright dangerous case…an offline qube that has a default DVM set on it…that actually does network.

The settings window will try to warn you about this with yellow triangles, but it took me a while to realize you had to hover over the triangle to see what it was trying to warn you about (I kept trying to push it like a button).

This isn’t an issue if your offline qube has an offline DVM…but I just this moment realized. You’re not talking about the disposable (which was my original topic), you’re talking about the network VM.

Of course, everything I just said applies to that too, and my default there is also set to none, just as you said. It’s a lot easier to realize, when you create a new qube that is supposed to talk to the internet, that you forgot to provide the network (and then fix that) than it is to realize a qube you thought was offline, isn’t. In the first case, you’ll try to do something and not be able to; in the second, you probably won’t ever try to do the thing you shouldn’t be able to do. Therefore, you might not notice the latter, ever, just in the course of trying to use the thing; you’d have to see the setting.

But again, I can understand why, as installed, the default is to connect to the network (unless it’s a template), because otherwise some new user will not be able to and not know why. I don’t recall for sure, but I think the pre-canned setup has Vault set up with no network.

The very first customization I did to qubes was to create a second firewall and network qube, and give those qubes the ethernet adapter, leaving wifi to the original firewall and network. That way my two networks are separated from each other. Later on with minimal templates, I don’t even have the driver for ethernet on the wifi net qube, and vice versa, so even if I were to accidentally put the wrong device on the wrong net qube, it couldn’t be (mis)used.

9

Except vault, sys-audio and cacher, I have no non-disposables, so I’m all in dvm-templates. Deleted anon-whonix, unstrusted, work and personal as well… Everything based on minimals.

Yep.

How did you remove it, I am genuinely interested in?

10

I removed it by going minimal template and not installing it! I’m not sitting on that system right now or I’d look at the salt files and tell you for certain, but IIRC one “network driver” was for the ethernet, and the other two or three had to do with wifi, or vice versa, so I just made sure to put ethernet driver(s) on deb11m-sys-net-ether, and wifi driver(s) on deb11m-sys-net-wifi. (Template VMs, on which the actual sys-net-ether and sys-net-wifi depend.)

I’ve still got the whonix stuff, though I rarely use it. “untrusted” “work” and “personal” are gone, only because I compartmentalize things very differently than that. Nothing wrong with them, they just didn’t fit me. I still have something roughly corresponding to vault but it’s named differently now, to fit in with my own peculiar naming scheme.

Of course the thing about going to dvms (and I am headed that way) is that even dvms will be assigned a default dvm if you don’t arrange otherwise! And it’s even more humorous if a dvm is its own default dvm; you can find yourself in an infinite loop of dvms opening other copies of themselves sometimes, if they’re handed a file they don’t know how to deal with.

I suppose a useful distinction can be made between a one-shot disposable (for opening, say, a jpg you don’t trust or making it safe) versus one you use for routine work. (This is a distinction in how we use it, not a meaningful distinction at the system level.) The former probably shouldn’t have a default dvm, ever. The latter of course, you might want one in case you come across a dodgy .jpg while (for instance) dealing with e-mail in your disposable. And of course the default install of QubesOS sets up one shot dvms, people like us migrate things like work and personal to routine-work dvms as time goes on.

Right now, I’m in a situation where a named disposable is probably a “routine work” disposable (which might usefully have a default dispvm) whereas the one-shot ones will be disp5678 type. I was thinking of going to numbered disposables for some of my “routine work” disposables, so that they’d shut down automatically, but now I’m reconsidering. (For one thing a meaningful qube name in the title on a window can be useful.)