Sys-net disposable? (4.1 rc)


on installing the 4.1 rc I have the choice to make sys-net disposable. What is the benefit / downside of this feature?

The benefit, as when using any disposable sys-vm, is that if the vm was compromised, a simple restart should solve the issue, and if you happen to restart often, then any hypothetical compromise should be short lived.

The only downside I’ve seen for sys-net, is that network config won’t persist, this may not be an issue if you’re using ethernet only, but for wifi it can be troublesome, so you will need to persist wifi details in /rw and restore the config using rc.local / bind-dirs

1 Like

As I get it “truly disposable” VM always uses defaults and has no persistence even on private volume?

You’re right @arkenoi, /rw will get wiped on restart as well so you’d need to make a custom disposable vm template just for sys-net (as you don’t want wifi credentials being readable by other sys-vms) and add your wifi info there.



there still some trace, it might not noticeable since most of there are log but there still some data left



Let’s start by reading this and then discuss what if anything is still unclear.


Basically, the network configuration isn’t stored when sys-net is shut down.


  • When you start sys-net, your wifi antenna doesn’t scream SSIDs (and potentially passwords) you’ve previously connected to, which, depending on your circumstances, can be beneficial. (If someone is listening, they won’t hear “STARBUCKS WIFI? STARBUCKS WIFI? WHERE ARE YOU? IT’S ME! MAC ADDRESS XX:XX:XX:XX:XX:XX! REMEMBER ME? I’M BACK!”)
  • If something does get into sys-net, it’s gone with a simple reboot of sys-net (at least, that’s the plan).


  • You’ll basically have to enter in passwords/keys every time you start sys-net. Some people consider this an inconvenience.
  • There is potential that you could confuse some wifi access points (particularly corporate networks that require installed certificates, etc.), setting off their man-in-the-middle precautionary measures (If you’ve ever tried to ssh into a completely different machine with the same IP address as one you’ve connected to before [listed in ~/.ssh/known_hosts], it’s similar to that…), causing the access point to potentially refuse to talk to you. (Unlikely, though…)

Your choice whether you think this will benefit you. It all depends on your circumstances :slight_smile:

1 Like

sorry, i mistake think it appvm and not dispvm

1 Like

If Im not mistaken I can switch the sys-net being disposable or not in the sys-net settings / advanced / other → disposable temple [x].
Or do I have to keep the choice I made during the installtion?

That’s possibly sufficient for most of us. In theory though, the something can still persist by reflashing any firmware on the network cards attached to sys-net, and making the VM disposable does not help with a thread of that level of sophistication.


That’s not a theory. That’s exactly how onboard device firmware upgrades work.

Definitely a valid point, @yann, and needs to be taken into consideration. Know your machine!

1 Like

You can do this after you installed a Qubes system. If you installed Qubes with sys-net ‘from fedora-xx-template’ you just have to do some commands in the dom0 terminal to change your current sys-net from templateVM to disposableVM.
I did this today and it worked fine, but note the conns, some people have written above.

And yes! You always can switch back to the old state, if you run into problems IF you don’t delete the old sys-net, which become a ‘copy’ in your Qubes list in the Qubes Manager.

1 Like

for those using minimal VMs (advanced users) it is possible to put passwords for the most frequent wi-fi APs in the disposableVM template.
I think that reduces the annoyance that is to enter password each time for every reebot.
But you need the one template just for that, otherwise you introduce security riscs. (I think)

Not possible even for minimal templates, as equbes wrote:

So if you’re an advanced user, you can try to persist the passwords in the mentioned files.