tempest
August 11, 2021, 1:36pm
305
does the host firewall need to be an issue here? currently, on numerous other implementations of whonix, no such firewall configs are used. would a solution be to have the typical “all incoming ports” disabled with the standard disclaimer that the host itself should not be used for standard workstation activities?
as a side note, i don’t think restricting network traffic to the gateway will work. it would prevent system updates on the host os. so, there is going to need to be an allowance for some host network activity.
i’m very glad to hear that progress is still being made here. but, if it’s near done, i’m not sure the lack of a perfect custom firewall should block release.
Patrick
August 11, 2021, 3:21pm
306
That has potential to generate a bad reputation.
For sure.
Implementing a host user clearnet is simple. (Similar to Whonix-Gateway user clearnet.) White listing VM traffic is a lot harder.
There’s a lot more todo.
https://forums.whonix.org/search?q=%23status_open_issue_todo%20%23component_whonix-host%20%20tag%3Acomponent_whonix-host
https://phabricator.whonix.org/project/view/26/
Not all has to be done but essentials seems to be EFI boot support, SecureBoot support, Anon Connection Wizard host support, an installer ISO that works for both EFI and non-EFI booting (⚓ T979 co-install grub-efi-amd64 and grub-pc by default on Whonix-Host ISO ).
tempest
August 26, 2021, 3:05am
307
maybe not? since whonix host will be using kvm, all that traffic should be owned by user “libvirt-qemu.” it’s not as perfect as filtering by vm name. but, it’s a start and narrows traffic down a little bit.
or, here’s another idea, what about filtering by source ip? for example, the whonix gateway in the kvm version has the local ip address on the host of 10.0.2.2. could this not effectively serve as a “virtual machine name” in implementation?
1 Like
Patrick
December 13, 2022, 1:11pm
309
3 posts were merged into an existing topic: Whonix’s Host naming
Patrick
February 25, 2023, 2:56pm
310
Having a hybrid ISO for USB / DVD that supports BIOS legacy boot, EFI boot and SecureBoot is a difficult task.
Hence I am now investigating porting Kicksecure / Whonix’s build script (derivative-maker) to Debian’s live-build which can do all of the above.
Patrick
February 27, 2023, 4:42pm
312
1 Like
Patrick
April 5, 2023, 8:18am
313
Patrick
December 5, 2023, 4:37pm
314
For our dracut based Live ISO there was this dracut usability bug which made the ISO unbootable.
opened 10:39PM - 23 Feb 23 UTC
bug
dmsquash-live
regression
**Describe the bug**
In dracut 058/059, with commit https://github.com/dracutde… vs/dracut/commit/8caaad4fc2d75982eb87f5ebc72a4c276986f756 and follow-up https://github.com/dracutdevs/dracut/commit/40dd5c90e0efcb9ebaa9abb42a38c7316e9706bd , overlayfs setup was moved from being done in-line at the end of `dmsquash-live-root.sh` to being part of a separate module. There were four codepaths in which overlayfs setup was reached in `dmsquash-live-root.sh`, but with the move to a module, only one of those paths now results in overlayfs setup happening. On the other three paths, it no longer happens, and boot fails.
**Distribution used**
Fedora 38 and Rawhide.
**Dracut version**
058 and 059.
**Init system**
systemd.
**To Reproduce**
Boot a Fedora installer image built with dracut 058/059 without the offending commits reverted. They were reverted in https://koji.fedoraproject.org/koji/buildinfo?buildID=2157455 and we caught this before it reached a nightly compose, so you would have to build your own image using the older dracut-059-1 build; the images built by openQA (which caught this bug) have been garbage-collected now. Affected images get stuck in a loop, showing the error "mount: /sysroot: special device LiveOS_rootfs does not exist."
**Expected behavior**
The image should boot normally.
**Additional context**
I did a detailed root cause of the problem in [the downstream bug](https://bugzilla.redhat.com/show_bug.cgi?id=2172269). Basically, if you look at `dmsquash-live-root.sh`, the overlayfs setup previously happened near the end of the file, any time the variable `$overlayfs` was a non-zero-length string. There were four paths on which that happened: one where it was set to "yes" (when `rd.live.overlay.overlayfs` is on the cmdline), and three where it was set to "required" (two inside the block that starts `if [ -z "$setup" -a -n "$devspec" -a -n "$pathspec" -a -n "$overlay" ]; then`, and one in the block that starts `if [ -e /run/initramfs/live/${live_dir}/${squash_image} ]; then`).
When the overlayfs setup was moved to a module, only the first of these paths was respected: the new module only actually does the overlayfs setup if the cmdline parameter set. In all other cases it exits after doing nothing. So on those three other paths, the overlayfs is not set up and boot will likely fail. Fedora's installer images go down the squashfs path, I don't know in what situations the other two paths are hit.
For now in Fedora we have reverted the relevant commits. @lnykryn [suggested](https://bugzilla.redhat.com/show_bug.cgi?id=2172269#c5) having `dmsquash-live-root.sh` do `echo "rd.live.overlay.overlayfs=1" > /etc/cmdline.d/dracut-need-overlay.conf` on the affected paths, which...I guess could work, but seems very hacky. I was kinda assuming there must be a better way to do this, some canonical way for such a script to signal to a module that its action is required?
This long standing development blocker might now be fixed:
adrelanos:master ← DanWin:master
opened 02:32PM - 02 Dec 23 UTC
The `dmsquash-live` module needs to be explicitly added for the live system to b… e bootable. However, it seems that the overlayfs is not created properly by this module, thus the generated `sysroot.mount` unit is failing. As a workaround, adding the `rd.live.overlay.overlayfs=1` cmdline option seems to do the trick. I could successfully boot the image with these changes.
1 Like
Patrick
December 9, 2023, 1:41pm
315
documentation on grub-mkrescue:
Patrick
December 9, 2023, 2:49pm
316
Major progress has been made. A script that can convert a raw image to an ISO image has been developed.
https://github.com/Kicksecure/grml-debootstraptest/blob/master/image-to-iso
Patrick
December 16, 2023, 11:23am
319
The problem is now that Secure Boot is unsupported. This is because the ISO doesn’t integrate with shim.
And installing shim inside a Debian bootable ISO is undocumented and difficult for me.
grub feature request written just now:grub-rescue ISO Secure Boot / shim support
That feature request could take a long time if it ever materializes.
It will be possible without that feature request being implemented too but then additional options have to be passed to grub-rescue (or mkisofs) or other tools have to be used (manual use of grub-mkimage). The code / options to do this can probably be extracted from Debian’s live-build but that’s something that I wanted to avoid because that is very difficult for me.
Patrick
January 3, 2024, 10:41am
323
Debian Live:
cat /etc/fstab
overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0
