Your disposable templates should now launch and shut down properly.
Disposable FirewallVMs
You can now create disposable FirewallVMs based on your disposable template. I recommend replacing sys-firewall with a disposable Mirage firewall. If you use ProxyVMs like sys-whonix, I recommend that you add a disposable Mirage Firewall after the ProxyVM as well, and use it as the net qube for your AppVMs.
I use and promote use of Mirage across the board. It’s fine for
everyday use.
I package mirage for a simple install - https://qubes.3isec.org/tasks.html
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
While I see the advantages of mirage, you have to know all the firewall rules in advance, which I think is unrealistic for desktop-app firewalling. The only approach that makes sense for a firewall for desktop-apps is confirm/reject while connections appear.
Mirage processes the standard Qubes firewall rules, and is a drop in
replacement for sys-firewall, so there’s nothing particular here about mirage.
I’ve tried using snitch in Qubes before, and frankly found it unusable.
Ordinary users with a few standard qubes are fine, (if they understand the
prompts), but mix in multiple qubes, disposables, etc, and prompt
overload hits fairly soon, and at that stage it’s worse than nothing.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
@unman Qubes-Snitch is something I wrote recently, its explicitly for Qubes.
mix in multiple qubes, disposables, etc
Qubes-Snitch can manage that. I use it with “kuhbs”, the Qubes config management system for appusers I’m working on rn (think appstore), so you can setup firewall rules for something like Signal-Desktop (AppVM) or “browser” (unnamed disposable) and alike.
Qubes-Snitch isn’t ready for production yet, but certainly worth a look.
Less RAM
That is a solid point, yes.
Mirage processes the standard Qubes firewall rules
Ah true, I forgot about that.
But still, I find that to be utterly unusable. If you have something like Signal-Desktop for example, that wants to talk to a new IP every now and then because CDNs and alike.. I find the classic qvm-firewall managed model to be not flexible enough.
Approving / denying traffic as it comes gives for much more flexibility, which imho is kind of required for desktop applications.
Static firewalls are more of a server thing, imho.
Rules are stored in yml files, from which nftables rules are generated. DNS is processed in dnspython (yes yes I know, but I think its ok). So you can reject DNS as well, but has to be over udp/53 and has to be half way sane DNS (I don’t parse all of it, but most of whats half way sane).
Not to much more to it. It has a DNS cache in memory, so you can accept a whole block of IPs in an A record (saves time like nuts).
It really is very simple to use. For DispVMs you can either create rules that are deleted after the VM disappears, or you can use rule-templates based on the AppVM.
It wants a bit of info via qrexec so it understands which IP belongs to which VM name, so it can store the rules you create before or on-demand.
If you mean usability, I highly disagree. In order to even know what you put into the allow-list you need to tcpdump/wireshark applications. Thats very user-unfriendly.
All my AppVMs run behind an VPN-VM. When I replaced sys-firewall with mirage-firewall, AppVMs behind a VPN worked. But the disposable VMs with direct internet access no longer had internet access. I don’t know why and can’t figure out the problem myself. I reverted back to sys-firewall.
I use a bunch of mirage firewalls and I think it’s a great service. A tenth the memory footprint of a minimized sys-firewall, instant boot and shutdown. There are a couple gotchas (throughput, and need to reboot sometimes) but otherwise it’s a free, significant resource win.
You do the sniffing on sys-net or sys-vpn, after the Mirage or plain sys-firewall. Then adjust the firewall settings and check that the undesired traffic is really not getting through anymore.
You do the sniffing on sys-net or sys-vpn, after the Mirage or plain sys-firewall. Then adjust the firewall settings and check that the undesired traffic is really not getting through anymore.
Correct. I find that utterly user-unfriendly. I know how this works, and I have the tech-skills to do so, but pretty much no regular Linux (end) user has, and newbies to Qubes can simply not make use of the firewall at all.
You can not expect people to mess with tcpdump/wireshark to setup a firewall. Thats a high-skill level thing.
And IMHO that is so severe a security “flaw” that I would almost call it a bug. Hence I wrote Qubes-Snitch.
Mirage is MUCH cooler than Qubes-Snitch because its so tiny (ressources), but not usable for (almost) everybody except tech savy people (same as the regular Qubes OS firewall).
You can give Qubes-Snitch to an enduser, explain for a few minutes how “traffic” and “DNS” works in an abstracted way, and they are ready to use it.
Give mirage to an enduser and ask him to configure it
Don’t get me wrong, Mirage firewall is fucking amazing, but I’m a bit on a quest to get regular users onto Qubes. They deserve good security too. And its not just that. So many things - setting up a good firewall is a PRIME example imho, are just to annoyingly complicated in qubes. I don’t want to f-ing wireshark around to setup a firewall. This has to be faster and simpler.
I have the tech skills for this, I’ve been using Qubes since I think Qubes 2 or so, and I LOVE it, but some things are just annoying. Firewall is one of my favorite examples.
When I change mirage’s netvm it will require such a reboot sometimes. I’m not sure how often exactly, but it does happen (this is not something I do on a consistent basis).