Sys-net disposable? (4.1 rc)

Hi,

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.

4 Likes

elaborate?


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

@ppc:

elaborate?

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

4 Likes

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

PROS:

  • 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).

CONS:

  • 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:

3 Likes

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?

1 Like

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.

4 Likes

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!

2 Likes

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.

2 Likes

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)

2 Likes

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.

Would you mind sharing the commands?
I like to be able to switch back in case I change my mind.

1 Like

I cannot enter only my home WIFI password into the disposable sys-net template so I get the best of both worlds, no persistence after reboot but it does remember the one or two most frequently used networks? Or would that defeat the purpose?

Commands are as follows and can be read here.

Cons for using a sys-net from a disp template:

  • while LAN is always connected, you have to choose WLAN and insert WLAN key on every new boot up

Cons for using sys-usb from a disp template:

  • if you don’t have a PS/2 keyboard and created a sys-usb qube, you run into troubles, because disposable qubes can’t be restarted (they just have to be in 2 steps shut down and start right after)
3 Likes

I have two questions about sys-net disposable. And excuse my lack of knowledge. The answer could have been already in this thread, but I need to verify.

I currently have wifi set to “disable” on boot (via a command in /rw/config/rc.local). How can I replicate that when I have a disposable? I mostly use ethernet connection.

I currently have MAC address randomization in sys-net. How is that implemented in a disposable sys-nte?

Thanks in advance for your answers and time.

You can do this the same way as you did - on the /rw/config/rc.local in the disposable, but you don’t need this anymore in a disposable VM. Whenever sys-net will start, it forgot the Wifi passwort/key and so you always need to insert it again (and again on every new bootup). So without insert of the passwort the wifi can’t connect to any wifi network.

Same with the MAC randomisation - you always have to setup it new on every new bootup (sys-net start) or enable the switch under /rw/config/rc.local…

1 Like

I have my Wifi password in my vault and when I need my WLAN I just copy it. It’s not a big bother for me.

2 Likes