Would it make sense to have the mirage-firewall be available as a template, which could operate as a
disposable VM in the event there is an exploitable vulnerability?
Here’s a saltstack script which downloads and installs the mirage firewall:
Based on this bash script:
How can I run this saltstack script? Would you be kind to share instructions? Thank you.
AFAIK mirage-firewall itself is stateless. It won’t store data that is persistent across reboots.
it doesn’t even onboard the concept of storage apart into memory ![]()
If you want to get familiar with saltstack on qubes, I recommend this page:
If you don’t know how to use salt and still want to create a mirage firewall with a script, I’d rather recommend the bash script to be run in dom0:
Thanks. One more question. If you create a mirage firewall with a script in a Fedora Qube, is it expected that the sha512 checksum / hash of the output, the mirage-firewall.tar.bz2 file, to match the one posted here https://github.com/mirage/qubes-mirage-firewall/releases/download/v0.8.4/mirage-firewall.tar.bz2 ?
I guess yes, because the built binary is reproducible.
You have to use sha256sum vmlinuz (not 512, and not the archive tarbal), and yes it should ![]()
EDIT: not sure if you think about compile it by yourself (it should with the build_with_docker script in the qubes-mirage-firewall github repo), or you want to check the vmlinuz hash sum after downloading (in that case it should if you download the latest release).
I compiled the mirage-firewall twice following the qubes-mirage-firewall github repo instructions in fedora-37 Qube, and using build_with_docker script.
And I downloaded the mirage firwall pre-compiled twice using different internet sources.
sha256 for vmlinuz in both compiled versions is the same: 848714b3d8e1d06d83e77ee688c32796f353fcafa7d8643db0e4d889b568e36e.
sha256 for the vmlinuz pre-compiled downloaded from github is the same: 55a2f823d66473c7d0be66a93289d48b6557f18c9257c6f98aa5a4583663d3c2.
So no, vmlinuz is not the same in the pre-compiled published version and the compiled version. Does this mean there’s a problem somewhere?
Yes, something isn’t clear here. I’ll check that tomorow.
Oh I think we’re into Reproducibilty considerations and tweaks · Issue #165 · mirage/qubes-mirage-firewall · GitHub and 3 weeks ago some package has been updated leading into that bad hashsum.
I also have the same docker hashsum as yours into my github actions (Main workflow · palainp/qubes-mirage-firewall@609f529 · GitHub) and I’ll PR to update to the right hashsum.
Thanks for the report!
The salt script fails if the check sum differs from the docker build according to this comment: Qubes R4.1 · Issue #173 · mirage/qubes-mirage-firewall · GitHub
I realized there is a simpler way. You just create the template and then in the settings window → Advanced
tab, you can check disposable template. Way simpler ![]()