Standalone (mirage?) sys-net/firewall/usb/whonix?

sadja · July 26, 2021, 4:08pm

Are there plans to include standalone, preferably mirage, vm’s for the sys-*? It seems like a no-brainer to me. It’ll be lighter and more secure. But I’m probably missing something!

fsflover · July 26, 2021, 4:25pm

github.com/QubesOS/qubes-issues

Idea: dynamic firewall

opened 01:34AM - 08 Aug 19 UTC

Rudd-O

C: core P: default T: enhancement

The Qubes firewall is an amazing piece of technology integration. That said, it… happens to be the case that many services these days change how traffic is routed to them using DNS, rendering it almost impossible to block based on DNS. For example: I boot up a VM that will run an app, which connects to `mxs-services.whatsapp.net` on port 443. If I configure this on the Qubes firewall, it will work... for the next thirty minutes or so. Then the DNS response changes -- the app requeries the DNS records, it receives a completely different set of DNS responses (most likely in a very different subnet), the Qubes firewall begins replying to TCP SYNs with `ICMP admin prohibited`, and the app simply stops working correctly. Endgame. The alternatives are to continually add new netblocks to the firewall configuration as they are discovered by manual inspection using a `tcpdump` terminal, or to completely abrogate security and open the machine up to leaks by allowing any and all traffic to the destination ports (most services these days just use port 443). Here's what I would like to see: * A service (associated to a firewall VM setting, and defaulting to **off**) that snoops on outbound DNS requests and incoming DNS replies from AppVMs attached to the firewall VM it's running on. * This service maintains an up-to-date cache of (host name -> IP addresses) sets. * This service also communicates with the Qubes firewall running on the machine. * Whenever the cache for a host name known to the Qubes firewall changes, it asks for the Qubes firewall to reset its rules * Alternatively, more correct and less racy, but harder: the service alters the firewall configuration by (1) crawling it, (2) deduces the host names from the IPs listed on it and expired versions of its cache, then (3) generates a new firewall configuration with the new non-expired IPs substituting the old expired IPs (4) applies the firewall configuration. * The service runs properly hardened, dropping any and all privileges it does not need. * The service is written in a memory-safe language like Rust. This would immensely improve the user experience of the Qubes firewall compared to the current system. It also has potential uses in split-DNS scenarios where a corporate user may or may not be logged into a corporate network some of the time, so the firewall really does need to respond to changes in network configuration. ## Ideas for extension Once the basics are in place, it should be possible to make the DNS firewall behave interactively. Imagine an incremental improvement whereby an AppVM not currently authorized to connect to `host.name.org` attempts to first resolve the address, then receives the response (duly-cached by the service I'm proposing). Now, the service sends its first TCP SYN. In principle, the service can detect this and present an "Outbound connection attempt prompt" (how best to wire this interactive protocol into the Qubes qrexec framework is left unspecified here), and then the user of the machine can say "Yes / No / Yes, always", upon which the firewall makes the policy decision of ignoring further TCP SYNs or allowing the connection to be established by adding the necessary rules and letting the AppVM retry the TCP SYN. The AppVM would not know this has happened -- the only side effect is that the connection will take longer to be finished due to exponential backoff. ## Pitfalls I have not yet considered if the service should independently snoop each VIF to separate how it'd change firewall rules (seems more secure that way). It might end up being necessary anyway, since it's important for such a service to maintain a per-VM high watermark of in-flight (not yet deemed complete) DNS requests, else the service be DDoSable by a misbehaving VM. ## Project management This seems worthy of at least a bit of funding. I believe I can pony up some. We can negotiate based on the effort estimated to get here. (If any of this could be implemented as a Mirage unikernel instead, or possibly a Unikraft unikernel -- which means it's not gonna be limited to OCAML -- so that it became a substitute for the standard Linux firewall VM offering of Qubes, I'd be even *more* interested in this project.)