Benefits of Sys-Firewall

[Claudio Chinicz]

Hi All,

Being a non technical user of Qubes, I'd like to ask the community about the benefits of using an additional VM between an AppVM and Sys-Net.

I do not configure Sys-Firewall and therefore it should be "all" open, right?

If I were to configure it for a specific purpose, like for a MailVM, I'd have to use 'clones' of Sys-Firewall, one for each specific purpose, correct?

So, I got confused. Is there a benefit for using Sys-Firewall without configuring it?

Thanks

[Sven Semmler]

When you configure firewall rules for e.g. email VM it is the
sys-firewall that enforces them. This point is critical, since otherwise
if your email VM get's compromised the malware could simply disable or
workaround the firewall.

You want your sys-firewall to be separate from sys-net for the same
reason: compartmentalization.

First of all, your sys-net VM needs to have virt_mode hvm (hardware VM)
because you assing the Wifi and Ethernet controllers to it. The sole
purpose of this VM is to provide connectivity, so even if it get's
compromised through e.g. a WiFi controller firmware issue ... there is
nothing in it of any interest to the attacker.

Ideally, if your traffic is encrypted (https, VPN, tor etc) the attacker
can't even spy on much other then which IP's you are talking too.

"Normal" VMs / qubes have virt_mode pvh which offers better security
(this is where my knowledge gets a little shacky). It is the default
type in Qubes R4.0. But a PVH can't have PCI devices assigned to it.

To recap:

sys-net: hardware VM with attached network controller
sees only traffic, no other information besides your
WiFi passwords is stored here

sys-firewall: PVH, enforces firewall rules for connected VMs
contains no information other then firewall rules
get network from sys-net

e.g. email VM: PVH, get network from sys-firewall and has
therefore no way around the rules enforced
by it.

The firewall rules are properties of your VMs and not available to the
VM itself.

I hope others will correct me if I got anything wrong.

/Sven

--
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

[dhorf-hfre...@hashmail.org]

On Fri, Feb 28, 2020 at 06:00:04PM -0600, Sven Semmler wrote:

> You want your sys-firewall to be separate from sys-net for the same
> reason: compartmentalization.

as usual "depends on your threat model".

if you are into outbound-firewalling of appvms, not doing so in the
appvm makes a lot of sense for the reasons you stated.
but you could do that in sys-net too, entirely without sys-firewall.

unless your threat model involves the same (or cooperating) attackers
compromising your sys-net from the outside that want to break out of
your appvm...

> I hope others will correct me if I got anything wrong.

looks good to me.
but i would like to add some off-default-config considerations/rambling.

what if your attacker has some l2-ish network linux exploit?
lets take something like CVE-2018-15688 as an example.
ipv6 dhcp problem, in both systemd and networkmanager.

afaik no one ever really evaluated the impact on a qubes system.
because ipv6 is "disabled" in the default config.
but what does that mean?
"ipv6 disabled in qubes" means ipv6 is disabled _within_ qubes.
as in, it is actualy enabled (by default) in sys-net in some ways,
just not forwarding it on the qubes-internal network links.

so worst case, an attacker can compromise your sys-net, then compromise
your sys-firewall, then your appvm. all with the same exploit, just
having to go hop-by-hop.

one way to mitigate a scenario like that is to involve something that
is _very_ much not linux. like qubes-mirage-firewall. or a bsd fw.
which of course is a "threat model" and "subjective considerations" thing.

because one side of it is ... it makes it much more unlikely for a
single attacker to have a walkthrough with a single exploit.
== it makes it less likely for an attacker to compromise the whole chain.

otoh ... now there are two ip stacks involved, and the mirage one
certainly got a lot less eyeballing than the linux one.
== it makes it more likely for an attacker to compromise part of your chain.

and there are "env" factors to consider too.
sure, if you dont have the ram to run separate linux based firewall vms,
go ahead and dump all of it (inkl sys-usb) into sys-net.
or your HW doesnt have (usable) IOMMU and you run your sys-net/sys-usb
pci-vms as "pv" instead of "hvm".
your overall security posture will (probably) still be better than with
a plain linux (or anything else) system, even though you take some
shortcuts that are not default config or recommended.

qubes provides a lot of different options there, with a reasonable
default config, but (depending on your threat model) going beyond
that can be quite reasonable too.

[Claudio Chinicz]

Thanks you dhorf and Sven for explaining the subject. I've learnt from your words.

Best Regards