Porting Whonix to Void Linux

What about Void Linux? It’s not listed on the wiki and seems to fix nearly everything.

  • It’s rolling release so we get security fixes
  • Uses musl instead of glibc
  • Uses runit instead of systemd
  • Uses LibreSSL instead of OpenSSL

The only thing messing is Clang CFI.

1 Like

Sure, we can complain that no distro is perfect yet, and that things need to be fixed at different levels than low-level init systems and system libraries. However, even if everything was sandboxed, there might still be issues in that sandbox, and so on. Thus it’s still a good idea to try to achieve higher security at every level, and while Void Linux isn’t actually focused on security that much, it’s choice of software and it’s release model don’t make it too bad for that either (as madaidan explained above, which I believe is partially due to me suggesting it to him somewhere else). Moving to a different kernel altogether is also not really a viable solution. The BSDs and other monolithic kernels don’t improve much, and most microkernel-based OSes such as RedoxOS are not really ready to be used as a daily driver OS, not even in a VM. So, what would need to be done to rebase on Void Linux? I’m going to list some things I can think of.

Obviously, it will somehow need to be made clear to all current Whonix users that the current Debian base is deprecated. Furthermore, some things will need to be packaged in the XBPS format. What is currently missing, possibly among others, is linux-hardened, TBB and LKRG. Current services specific to the systemd format would need to be rewritten - for example, the one that is responsible for the LKRG. This shouldn’t be too hard however, since the scripts that Runit uses for services are quite simple - most of the time it’s just something like
#!/bin/sh
#Maybe do something
exec somedaemon.
What may be a bit harder is to sandbox these services. Unlike systemd, Runit doesn’t bring an integrated sandbox (which may be a good thing, as they let others focus on writing good sandboxes which can also be used in other contexts, while they just focus on the basic supervision suite itself), so something like Bubblewrap is recommended. Runit’s chpst is not a proper sandbox afaict, just some frontend for managing cgroups and some other basic process resources and such.

Regarding X11, this is not a problem of any specific distro, but rather of the desktop environment, as mentioned. I see two different approaches to solving this issue.

  1. Hope that Xfce becomes compatible with Wayland at some point. If at all, I don’t believe this will happen in the near future, as Xfce’s release cycle is very slow due to it being such a small project (just like Whonix).
  2. Rebase on a different DE. I currently see three options here: Sway, Plasma and GNOME3. Either of these would mean minor to major changes in how user friendly Whonix is and in how people will interact with its GUI. The two latter ones will also possibly make it slightly slower/heavier (though not much) than before, though this may not be as much of an issue, as staying on X would let the need for something like Xpra emerge, which would also have an impact on performance. Yes, there are other DEs and compositors, however from my understanding, these are either not finished, or, in the case of Enlightenment, use a terrible library; EFL. Personally, I’d rather have Plasma or Sway than GNOME, and I think most would agree, since the latter is quite controversial, and if you really like the GNOME3 menu, Plasma has something similar as an option as well. Perhaps it would be possible to offer alternate spins using Wayland DEs, if it’s not too much work? Of course one could also simply write a tutorial or so for users on how to change it (I guess I could do that as well, if necessary).
1 Like

It’s not a decision to take lightly to say the least due to the amount of work this generates. And if that’s wrong, if that is in fact easy, then why isn’t it done… There’s two anonymity focused operating systems left, Whonix and Tails. Both based on Debian.

I am also not sure it’s even useful to spend a lot time on debating this.

It’s also too complex to resolve it through debate. A counter argument why it’s in vain, worse, etc. is always around the corner.

Therefore if you want to increase chances of this happening, please work on this wiki list Criteria for Choosing a Base Distribution which should be converted into a comparison table.

Whonix used to be based on a “mostly” rolling distribution, Debian testing.

Security-Focused Operating System Comparison as Base for Whonix

That was difficult to maintain to say the least.

Intuition tells that moving from one distribution that does not have security as a primary goal to switch to another distribution that does not have security as a primary goal is at high risk of wasting time and work.

Please keep that someone generic and then help maintain ToDo List for Porting to another Base Distribution.

Looks a lot harder to me since systemd also support dependencies, before=, after=, sandboxing, drop-in config files for systemd units of other services, tmpfiles.d.

number of files matching /systemd/ in Whonix source code: 136 (a lot trivial / auto generated).

Related:

“Just” finished porting away from KDE (severe performance issues) to XFCE which was great.

Or no desktop environment, just pick and choose.

I would dislike to spend time on xpra until options for wayland are exhausted, see use Xfce with Wayland

Yes. The desktop environment discussion can easily lead to law of triviality / bikeshed. More convincing to see performance test results / ports.

Porting Whonix to XFCE as far as I remember back initially wasn’t debated but convincing screenshots / implementation / performance was shown as per Whonix Xfce Development.


Needs solid technical documentation / comparison / proposal. Then should ask friendly security experts for feedback. I don’t think anyone has resources available for this currently but happy to be proven otherwise.

1 Like

Thanks, I will look at how to contribute to both.

I think that this will not be the case for every rolling release distro however. In my experience, Debian Testing (and probably Unstable as well) breaks far more often than any other RR; I partially use Void Linux as my daily driver distro and, unlike in Debian Testing, I didn’t encounter lots of bugs, let alone system breakage. Also see https://wiki.voidlinux.org/Frequently_Asked_Questions#Is_there_a_.27Stable.27_version_of_Void.3F :

There are linux distros that release to a periodic cycle, Void does not, instead provides a continual steam of updates, which makes it a rolling release. On the other hand there are bleeding edge distros, that gives the latest software as soon as possible after its release. This is not what Void does and although some software is updated frequently, it is by no means as soon as possible or come what may.

It’s all about having a good base for a security focused distribution like Whonix. Such a base doesn’t necessarily need to be security focused as well.

Are all of those 136 files specific to Whonix? I’m asking since standard services that are not specific to Whonix are mostly available for Runit as well, or maybe not even needed (for example, NM can be replaced by dhcpcd in many cases). As for dependencies, it is possible (see Runit or Void documentation, or maybe even Artix wiki for reference). However, yes, it is not as sophisticated as systemd in that regard. I mentioned sandboxing, personally, I think it’s a good thing to split up tasks between programs (UNIX philosophy), unlike systemd, which does everything itself. Thus, I recommend using an external sandbox like Bubblewrap, and yes, as I said, this would be more work.

Of course. But probably not an option for less tech-savvy users.

Xfce with Wayland would be appealing, given it will work. I just mentioned Xpra because staying on X would require that, however it’s a much worse “solution” than simply using Wayland.

2 Likes

The idea is that Whonix developers would provide that pick and choose, pre-configured. Not users. The end result should be similar to what XFCE (or another DE) is doing now. For example somehow using XFCE with another window manager to make it use wayland, if that is doable. ( use Xfce with Wayland ) Or a similar solution (pick windows manager + wayland + taskbar + systray applications)…

Yes. All drop-ins / systemd units by Whonix.

See:

Download Whonix source code as per:

Build and Update Whonix from Source Code

cd packages

find . -type f -not -iwholename '*.git*' | grep /systemd/

(Probably want a shortcut for find.)

A lot in ./qubes-whonix/lib/systemd/system/ are trivial files that could and should be merged.

For example ./qubes-whonix/lib/systemd/system/swap-file-creator.service.d/40_qubes.conf into ./rads/lib/systemd/system/rads.service.

Let’s subtract these for now.

Let’s also ignore the auto generated ones:
./anon-ws-disable-stacked-tor/lib/systemd/system/anon-ws-disable-stacked-tor_autogen_*

Let’s also ignore .conf (which are mostly just trivial [1] drop-ins).

find . -type f -not -iwholename '*.git*' | grep /systemd/ | grep --invert-match qubes-whonix | grep --invert-match disable-stacked-tor | grep --invert-match \.conf | wc -l

36

i.e. 36 “real” systemd unit services by Whonix. Looks more managable to port elsewhere.

./sdwdate/lib/systemd/system/sdwdate.service
./dist-base-files/lib/systemd/system/dist-skel-first-boot.service
./whonix-libvirt/lib/systemd/system/whonix-libvirt-set-persistent-mode-to-read-write.service
./whonix-libvirt/lib/systemd/system/whonix-libvirt-set-live-to-readonly.service
./whonix-libvirt/lib/systemd/system/whonix-libvirt-install.service
./whonix-firewall/lib/systemd/system/whonix-firewall-restarter.service
./whonix-firewall/lib/systemd/system/whonix-firewall.service
./bootclockrandomization/lib/systemd/system/bootclockrandomization.service
./lkrg/scripts/bootup/systemd/lkrg-systemd.sh
./lkrg/scripts/bootup/systemd/lkrg.service
./swap-file-creator/lib/systemd/system/swap-file-creator.service
./apparmor-profile-dist/lib/systemd/system/live-mode-apparmor.service
./tor-control-panel/lib/systemd/system/tor-control-panel.service
./whonix-legacy/lib/systemd/system/whonix-legacy.service
./security-misc/lib/systemd/system/permission-hardening.service
./security-misc/lib/systemd/system/proc-hidepid.service
./security-misc/lib/systemd/system/remove-system-map.service
./security-misc/lib/systemd/system/remount-secure.service
./security-misc/lib/systemd/system/hide-hardware-info.service
./security-misc/lib/systemd/system-preset/50-security-misc.preset
./rads/lib/systemd/system/rads.service
./rads/lib/systemd/system/rads-block-display-manger.service
./tb-updater/lib/systemd/system/tb-updater-dispvm.service
./tb-updater/lib/systemd/system/tb-updater-first-boot.service
./timesanitycheck/lib/systemd/system/timesanitycheck.service
./corridor/systemd/corridor-init-forwarding.service.in
./corridor/systemd/corridor-init-logged.service.in
./corridor/systemd/corridor-data.service.in
./corridor/systemd/corridor.target
./corridor/systemd/corridor-init-snat.service.in
./sdwdate-gui/lib/systemd/system/sdwdate-gui-shutdown-notify.service
./whonixcheck/lib/systemd/system/whonixcheck.service
./onion-grater/lib/systemd/system/onion-grater.service
./msgcollector/lib/systemd/system/msgcollector.service
./msgcollector/usr/lib/systemd/user/usertest.service
./kloak/lib/systemd/system/kloak.service

Even of that list some are not important such as corridor (no immediate port required) or lkrg (part of upstream source code but not in use).


[1] example:

Was non-trivial to invent:

cat ./anon-gw-anonymizer-config/lib/systemd/system/vanguards.service.d/30_anon-gw-anonymizer-config.conf
[Service]
Environment=VANGUARDS_CONFIG=/etc/tor/anon-vanguards.conf

But is trivial for developers to understand.

1 Like

So something like Security-Focused Operating System Comparison as Base for Whonix?

2 Likes

Yes, that’s an very good start.

1 Like

So, Xfce was used because it is more lightweight than Plasma. However LXQt is even more lightweight, and they’re actively discussing the move to Wayland (https://github.com/lxqt/lxqt/issues/10), though from what I understood, this probably won’t happend before Qt6 is released. Just mentioning it as an option for the future.
EDIT: JUst noticed I posted this in the wrong thread - should have been in “Fixing the desktop Linux security model”. Anyway, it’s not completely off topic here either.

2 Likes

I just edited the two wiki pages mentioned by Patrick slightly (mostly minor changes).

Qt (the company) is fucking with the license and essentially locking out open source projects like KDE. Might have something to do with hiring an ex-(?)MS Shill. There’s talk of forking the said project into Kt and making it Wayland compatible before the at least 2 year artificial delay caused by management.

1 Like

The lead Void dev just left.

Seems like everything will continue fine though.

1 Like

Link offline.

1 Like

It worked earlier. Must’ve been taken offline.

1 Like

There’s a good reason we use tier 1 distros as a base, they are more likely to stay around as dev interests shift.

1 Like

As described in the blog post on voidlinux.org that @madaidan linked, it’s just the original XBPS (and Void) developer leaving because of conflicts with him since he rejoined the project (he had already left once). They have quite a few devs, so it shouldn’t be a problem for them to continue without xtraeme/Juan RP.

Updated just now.