qubes-mirage-firewall 0.7

220 views
Skip to first unread message

ssch...@gmail.com

unread,
May 19, 2020, 9:11:14 AM5/19/20
to qubes-users
I'm pleased to announce the release of qubes-mirage-firewall 0.7:

 https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.7


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 64MB 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.


This version adapts qubes-mirage-firewall with

  • dynamic rulesets via QubesDB (as defined in Qubes 4.0), and
  • adds support for DNS hostnames in rules, using the pf-qubes library for parsing.

The DNS client is provided by DNS (>= 4.2.0) which uses a cache for name lookups. Not every packet will lead to a DNS
lookup if DNS rules are in place.

A test unikernel is available in the test subdirectory.

This project was done by @linse and @yomimono in summer 2019, see PR #96.


Additional changes and bugfixes:

  • Support Mirage 3.7 and mirage-nat 2.0.0 (@hannesm#89).
    The main improvement is fragmentation and reassembly support.

  • Use the smaller OCurrent images as the base for building the Docker images (@talex5#80).

    • Before: 1 GB (ocaml/opam2:debian-10-ocaml-4.08)
    • Now: 309 MB (ocurrent/opam:alpine-3.10-ocaml-4.08)
  • Removed unreachable Lwt.catch (@hannesm#90).

Documentation:

  • Add note that AppVM used to build from source may need a private image larger than the default 2048MB (@marmot1791,
    #83).

  • README: create the symlink-redirected docker dir (@xaki23#75). Otherwise, installing the docker package removes t
    he dangling symlink.

  • Note that mirage-firewall cannot be used as UpdateVM (@talex5#68).

  • Fix ln(1) call in build instructions (@jaseg#69). The arguments were backwards.

Keeping up with upstream changes:

  • Support mirage-3.7 via qubes-builder (@xaki23#91).

  • Remove unused Clock argument to Uplink (@talex5#90).

  • Rename things for newer mirage-xen versions (@xaki23#80).

  • Adjust to ipaddr-4.0.0 renaming _bytes to _octets (@xaki23#75).

  • Use OCaml 4.08.0 for qubes-builder builds (was 4.07.1) (@xaki23#75).

  • Remove netchannel pin as 1.11.0 is now released (@talex5#72).

  • Remove cmdliner pin as 1.0.4 is now released (@talex5#71).



qubeslover

unread,
May 23, 2020, 11:24:42 AM5/23/20
to qubes-users



Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, May 19, 2020 3:11 PM, <ssch...@gmail.com> wrote:

I'm pleased to announce the release of qubes-mirage-firewall 0.7:

 https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.7


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 64MB 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.


Excellent!

Built it in a Debian VM, copied the mirage-firewall kernel to Dom0, created a dedicated standalone VM (only 32Mb) and works great! (I am testing it as main firewall and so far no problem).

Is there any plan to create a package for Qubes Dom0 repo for the future?

Cheers.

ssch...@gmail.com

unread,
May 25, 2020, 5:23:08 AM5/25/20
to qubes-users


On Saturday, 23 May 2020 17:24:42 UTC+2, qubeslover wrote:

Is there any plan to create a package for Qubes Dom0 repo for the future?

Thanks for your interest! We are planning to collaborate with Qubes folks on packaging it. 
There is no timeline yet, stay tuned. 

dhorf-hfre...@hashmail.org

unread,
May 25, 2020, 6:03:42 AM5/25/20
to ssch...@gmail.com, qubes-users
On Mon, May 25, 2020 at 02:23:08AM -0700, ssch...@gmail.com wrote:
> On Saturday, 23 May 2020 17:24:42 UTC+2, qubeslover wrote:
> Is there any plan to create a package for Qubes Dom0 repo for the future?
> We are planning to collaborate with Qubes folks on packaging it.

there is
https://github.com/QubesOS/qubes-builder/blob/master/example-configs/mirage.conf
which builds mirage firewall (and ssh-agent) as a template-vm,
which reduces the problem to the more generic "how to ship/install
a template" (which can be handled entirely outside dom0 already)
as opposed to the very mirage-specific "how to install a vm-kernel in
dom0" (which is very dom0 oriented).

it actualy works well enough, i have been building+deploying all my
mirage vms for more than a year this way.

there are some points left to improve:

1) how to include vm-specific prefs/feats with a template pkg.
this mainly needs a way for a vm-specific builder to include
a file in the final rpm, and that isnt really straightforward
since the rpm-builder and vm-builder are like three layers of
abstraction apart.

2) "@tag:buildvm @tag:created-by-@srcvm allow" in qubesrpc-policy.
the "reference srcvm in dstvm spec" part doesnt exist.

3) automated way to create the pvgrub vm-kernel entry. (probably salt)

4) polishing. (which doesnt make too much sense as long as 1-3 are open)

these are not actualy required, but would make the whole thing a lot
more userfriendly.


bernhard haak

unread,
May 25, 2020, 12:22:25 PM5/25/20
to qubes...@googlegroups.com
On 5/19/20 3:11 PM, ssch...@gmail.com wrote:
> I'm pleased to announce the release of qubes-mirage-firewall 0.7:
>
>  https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.7
> <https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.7>

I try to build on buster, but already new-docker fails.

DKMS: install completed.
Building initial module for 4.19.120-1.pvops.qubes.x86_64
Error! Bad return status for module build on kernel:
4.19.120-1.pvops.qubes.x86_64 (x86_64)
Consult /var/lib/dkms/aufs/4.19+20190211/build/make.log for more
information.
dpkg: error processing package aufs-dkms (--configure):
installed aufs-dkms package post-installation script subprocess
returned error exit status 10
Errors were encountered while processing:
aufs-dkms


If I ignore it, (docker is installed, but incomplete), the build fails,
without surprise. Someone has a hint on that? Cheers, Bernhard

hut7no

unread,
May 27, 2020, 2:00:52 PM5/27/20
to qubes-users
Thank you so much for your work, I have saved so much time and memory because of your amazing firewall!
Reply all
Reply to author
Forward
0 new messages