qubes-mirage-firewall 0.6
Thomas Leonard
https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.6
This is a unikernel that can run as a QubesOS ProxyVM, replacing sys-firewall. It may be useful if you want something smaller or faster-to-start than the Linux-based sys-firewall. It requires around 32MB of RAM when running and requires "0.0s" of CPU time to boot, according to "xl list". It does not need or use a hard-disk, and does not persist any state between reboots.
For installation instructions, see:
https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md
To upgrade from an earlier release, just overwrite /var/lib/qubes/vm-kernels/mirage-firewall/vmlinuz in dom0 with the new version and restart the firewall VM.
For a blog post explaining the background for this, with a walk-through of the code (it's written in OCaml), see:
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/
Changes to rules language:
- Allow naming hosts (@talex5, #54). Previously, we passed in the interface, from which it was possible (but a little difficult) to extract the IP address and compare with some predefined ones. Now, we allow the user to list IP addresses and named tags for them, which can be matched on easily.
- Add some types to the rules (@talex5, #54). Before, we inferred the types from `rules.ml` and then the compiler checked that it was consistent with what `firewall.ml` expected. If it wasn't then it reported the problem as being with `firewall.ml`, which could be confusing to users.
- Give exact types for `Packet.src` (@talex5, #54). Before, the packet passed to `rules.ml` could have any host as its `src`. Now, `from_client` knows that `src` must be a `Client`, and `from_netvm` knows that `src` is `External` or `NetVM`.
- Combine `Client_gateway` and `Firewall_uplink` (@talex5, #64). Before, we used `Client_gateway` for the IP address of the firewall on the client network and `Firewall_uplink` for its address on the uplink network. However, Qubes 4 uses the same IP address for both, so we can't separate these any longer, and there doesn't seem to be any advantage to keeping them separate anyway.
Bug fixes:
- Upgrade to latest mirage-nat to fix ICMP (@yomimono, @linse, #55). Now ping and traceroute should work. Reported by @xaki23.
- Respond to ARP requests for `*.*.*.1` (@talex5, #61). This is a work-around to get DHCP working with HVM domains. Reported by @cgchinicz. See: https://github.com/QubesOS/qubes-issues/issues/5022
- Force backend MAC to `fe:ff:ff:ff:ff:ff` to fix HVM clients (@talex5, #61). Xen appears to configure the same MAC address for both the frontend and backend in XenStore. This works if the client uses just a simple ethernet device, but fails if it connects via a bridge. HVM domains have an associated stub domain running qemu, which provides an emulated network device. The stub domain uses a bridge to connect qemu's interface with eth0, and this didn't work. Force the use of the fixed version of mirage-net-xen, which no longer uses XenStore to get the backend MAC, and provides a new function to get the frontend one.
- Wait if dom0 is slow to set the network configuration (@talex5, #60). Sometimes we boot before dom0 has put the network settings in QubesDB. If that happens, log a message, wait until the database changes, and retry.
Reproducible builds:
- Add patch to cmdliner for reproducible build (@talex5, #52). See https://github.com/dbuenzli/cmdliner/pull/106
- Use source date in .tar.bz2 archive (@talex5, #49). All files are now added using the date the `build-with-docker` script was last changed. Since this includes the hash of the result, it should be up-to-date. This ensures that rebuilding the archive doesn't change it in any way. Reported by @h01ger.
Documentation changes:
- Added example rules showing how to block access to an external service or allow SSH between AppVMs (@talex5, #54). Requested at https://groups.google.com/d/msg/qubes-users/BnL0nZGpJOE/61HOBg1rCgAJ.
- Add overview of the main components of the firewall in the README (@talex5, #54).
- Link to security advisories from README (@talex5, #58).
- Clarify how to build from source (@talex5, #51).
- Remove Qubes 3 instructions (@talex5, #48). See https://www.qubes-os.org/news/2019/03/28/qubes-3-2-has-reached-eol/
ron...@riseup.net
Is there any way to verify that i'm now running 0.6 rather than an
earlier version?
Thomas Leonard
> On 2019-05-29 07:57, Thomas Leonard wrote:
> > I'm pleased to announce the release of qubes-mirage-firewall 0.6:
> >
> > https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.6
> >
> > This is a unikernel that can run as a QubesOS ProxyVM, replacing
> > sys-firewall. It may be useful if you want something smaller or
> > faster-to-start than the Linux-based sys-firewall. It requires around
> > 32MB of RAM when running and requires "0.0s" of CPU time to boot,
> > according to "xl list". It does not need or use a hard-disk, and does
> > not persist any state between reboots.
> >
> > For installation instructions, see:
> >
> > https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md
> >
> > To upgrade from an earlier release, just overwrite
> > /var/lib/qubes/vm-kernels/mirage-firewall/vmlinuz in dom0 with the new
> > version and restart the firewall VM.
>
> Is there any way to verify that i'm now running 0.6 rather than an
> earlier version?
When 0.6 boots, it prints a message like this, which earlier versions didn't:
INF [dao] Got network configuration from QubesDB:
NetVM IP on uplink network: 10.137.0.5
Our IP on uplink network: 10.137.0.19
Our IP on client networks: 10.137.0.19
So if you see that in the logs then you're running 0.6. But yeah, maybe it should print a version number somewhere too...
ronpunz
2019-05-29 12:38:50 -00:00: INF [dao] Got network configuration from
NetVM IP on uplink network: 10.137.0.5
Our IP on client networks: 10.137.0.30
It differs from your example but I guess its OK?