Thanks you dhorf and Sven for explaining the subject. I've learnt from your words.
Best Regards On Saturday, 29 February 2020 02:49:59 UTC+2, [email protected] wrote: > > 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. > > > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ffc9ee62-3159-40a8-b0a0-69910faecbfd%40googlegroups.com.
