Mullvad VPN setup guide

  1. Doesn’t matter, the templates are Linux and so is dom0. Services are run by Linux qubes, not the hypervisor. This statement is completely useless and doesn’t even apply to the discussion at hand.
  2. Doesn’t matter, most of the anti systemd people don’t know what they are talking about. Just because there are a group of angry people saying ridiculous stuff like the Suckless group or Devuan doesn’t mean that you bastardize your own system design to appeal to them.
  3. Doesn’t mean it is the proper way to do things, as demonstrated above.

And no, this is not how a system should be designed. If you care so much about being inclusive and providing freedom, the proper solution is to engineer the guest agent to cater to each operating system’s way of handling services. If Qubes were to be treated like a Hypervisor, it should work with everything, Windows, macOS, the BSDs, etc… not just those anti-systemd-for-no-sensible-reason distros.

If Qubes were to be treated like a Hypervisor, it should work with everything

Can you do it?

What are you even talking about at this point? That is just to show how the whole “hurr hurr Qubes is not a Linux distro” argument is ridiculous when you are trying to schedule a service inside of a systemd Linux system.

At this point I think we should just stop talking, because you clearly are insisting on not scheduling services properly cuz “hurr hurr Qubes has not decprecated rc.local yet its a fact!!!” and “systemd is controversial cuz the Suckess people say so!!!” regardless of how it is in reality. I have given you a concrete example of why it’s not proper, I don’t even know what else I can possibly give you at this point.

1 Like

When I asked:

That said, if you have arguments against it, have you reported it to GitHub?

you bombarded me with counter-questions:

It makes a mess out of managing services. How are you gonna run 2 concurrent services? How are you gonna manage logging for them? How are you going to their status? What about timers? Path? Runtime hardening?

which is not an answer.

Now you say:

What are you even talking about at this point?

I asked if you can do what you suggest. You are “answering” with a counter-question.

That is just to show how the whole “hurr hurr Qubes is not a Linux distro” argument is ridiculous when you are trying to schedule a service inside of a systemd Linux system.

I have never used the words “hurr hurr”. That is your way of discussing.

Qubes OS is not a Linux distro - that is a fact. It is a valid argument because you speak of “other distros”, implying that Qubes (not being one) should follow:

Just because qubes hasn’t deprecated it doesn’t mean that other distros have not done it.

In that sense, your argument is not valid (and note: I am not saying ridiculous, I am explaining why it is invalid).

Considering Qubes OS’s specifics, long-term, it may be improper to have it depend on systemd. Currently dom0 is too big and will hopefully be minimized one day. A minimal dom0 may use a different distro which will not use systemd, and that may be more appropriate from security perspective. I am not saying this will be so - that is up to devs to decide. I am just explaining there may exist valid reasons for other considerations, different from the desires of a single user, of multiple users, or of “most major” distros. In any case, templates are something different from the core and one should be able to use various OSs.

At this point I think we should just stop talking, because you clearly are insisting on not scheduling services properly cuz “hurr hurr Qubes has not decprecated rc.local yet its a fact!!!”

Where exactly did you see me insist on that?

and “systemd is controversial cuz the Suckess people say so!!!”.

This “cuz…” is another thing I have never said. Yes, systemd is controversial - that is a fact, regardless of the source and regardless of the labels you slap on those who don’t like it. That doesn’t mean I am against systemd (or for it), or “hurr hurr”. I am just saying it is controversial and that’s all. The “cuz…” is entirely your invention. I really don’t understand your desire to turn this into a fight.

I have given you a concrete example of why it’s not proper, I don’t even know what else I can possibly give you at this point.

A link to the GitHub issue, so we can all know what devs think about your suggestion. No need to get worked up.

This is literally just me talking about the general design of a hypervisor.

In that sense, your argument is not valid (and note: I am not saying ridiculous , I am explaining why it is invalid).

How is it invalid? The services are being scheduled on Linux, not Xen. If you were going to schedule service for Windows on Qubes, you have to cater to Windows’s way of doing things.

Considering Qubes OS’s specifics, long-term, it may be improper to have it depend on systemd.

No it’s not. It is proper for it to depend on how the guest OS expects to schedule services inside of the guest OS. It’s a fact.

Currently dom0 is too big and will hopefully be minimized one day. A minimal dom0 may use a different distro which will not use systemd, and that may be more appropriate from security perspective.

It absolutely does not matter what dom0 uses. You are scheduling services inside of Linux guest with systemd, therefore inside of those guests you should be using systemd. The init system for dom0 has no baring on how service scheduling is done in a guest. This is a fact.

Removing systemd to use a bunch of half-baked tools which can’t do the job properly like Suckless are not reducing the attack surface. If you care about security, you should be keep systemd and add runtime hardening for the services. That is a much better way to do attack surface reduction. Which other init systems support that? Are they actually doing the job more properly than systemd?

Yes, systemd is controversial - that is a fact, regardless of the source and regardless of the labels you slap on those who don’t like it. That doesn’t mean I am against systemd (or for it), or “hurr hurr”. I am just saying it is controversial and that’s all. The “cuz…” is entirely your invention. I really don’t understand your desire to turn this into a fight.

They cannot back it up with real technical arguments and their systems are terrible. You linked a completely incoherent post which just craps on systemd for no reason and advocates for a terrible init system which doesn’t even understand basic dependency management, let alone more advanced stuff like runtime hardening.

Anyone can make up any amount of ridiculous things about a product and make it “controversial”. It doesn’t mean anything.

How is it invalid?

Because it is comparing oranges (“other distros”) to an apple (not a Linux distro). In that sense, your:

Just because qubes hasn’t deprecated it doesn’t mean that other distros have not done it.

can be answered with the opposite, similarly invalid:

“Just because other distros have done X, doesn’t mean Qubes OS should do the same”.

The services are being scheduled on Linux, not Xen.

As discussed, there are non-systemd distros and those can be used as templates. If you mean that Qubes OS’s official templates that are systemd-based should implement a better scheduling of systemd units (with which, FWIW, I agree) - that is something entirely different from Qubes deprecating /rw/config/rc.local.

Considering Qubes OS’s specifics, long-term, it may be improper to have it depend on systemd.

No it’s not. It is proper for it to depend on how the guest OS expects to schedule services inside of the guest OS.

What I said was about dom0.

It absolutely does not matter what dom0 uses. You are scheduling services inside of Linux guest with systemd, therefore inside of those guests you should be using systemd.

Yes, for the templates, it does not matter what dom0 uses. My note was in regards to systemd and Qubes OS design in general.

Yes, systemd is controversial - that is a fact, regardless of the source and regardless of the labels you slap on those who don’t like it.

They cannot back it up with real technical arguments and their systems are terrible.

You continue with slapping labels - OK, that is your way. I am nobody’s advocate. Facts are facts - there are such systems, there are technical experts developing them:

The only thing that matters for Qubes OS is what you can suggest and what the devs will say about it.

I do not think you are posting in good faith at this point. It looks more like you are just trying to derail the thread.

Because it is comparing oranges (“other distros”) to an apple (not a Linux distro).

No, I am comparing the behavior of normal distributions and their counterpart inside of a Qubes template. This is Linux to Linux comparison.

“Just because other distros have done X, doesn’t mean Qubes OS should do the same”.

Sure, except using rc.local on systemd systems is bad practice.

As discussed, there are non-systemd distros and those can be used as templates. If you mean that Qubes OS’s official templates that are systemd-based should implement a better scheduling of systemd units (with which, FWIW, I agree) - that is something entirely different from Qubes deprecating /rw/config/rc.local.

No. They should be using what those distros expect. You can’t just make a blanket designation that oh it should be rc.local. It doesn’t even work the same way with different init systems.

You continue with slapping labels - OK, that is your way. I am nobody’s advocate. Facts are facts - there are such systems, there are technical experts developing them:

Once again, you have linked something that says absolutely nothing in relation to the topic at hand. You just listed some Linux systems that do not use systemd for various technical reasons, then use it to make it a “fact” that systemd is somehow controversial.

  • GrapheneOS, DivestOS, etc are Android variants. They are using a whole different system design based on AOSP, so of course they aren’t using systemd. This is not because systemd is controversial or so bad that they avoid it at all cost. These are not your traditional Linux desktop stack. Oh, and what do you think the developers of these OSes use on their servers/workstations? systemd. I know this for a fact.
  • OpenWRT and DD-WRT are meant for extremely underpowered consumer routers, so they need to strip them down as much as possible. It has nothing to do with systemd being controversial.
  • Alpine is generally meant for OCI containers, so they don’t need systemd by virtue of the fact that the entrypoint of a container is just 1 binary that it’s supposed to run.
  • etc and etc

The only thing that matters for Qubes OS is what you can suggest and what the devs will say about it.

You keep bringing this up as if it is some kind of “gotcha” talking point. Even if Qubes keep rc.local because of legacy cruff, it doesn’t change the fact that it is legacy stuff and shouldn’t be used on systemd systems, as I have demonstrated above.

No matter how you engineer it (be it through the qubes service or the rc-local service systemd used to provide), it will never work properly. It’s is impossible to guarantee something to “run last” because such concept doesn’t exist in systemd. Also, using something that actually “runs last” to run stuff is not proper service scheduling either.

Hello, thank you for your work.
Could you please tell me how to solve the problems with the broken link in your script?

I run this script on my template to trim it down:

sudo dnf -y install 'https://divested.dev/rpm/fedora/divested-release-20231210-2.noarch.rpm'
[MIRROR] divested-release-20231210-2.noarch.rpm: Status code: 404 for https://divested.dev/rpm/fedora/divested-release-20231210-2.noarch.rpm

Thanks in advance for your help.

New setup hardened_malloc:

sudo dnf -y install 'https://gitlab.com/divested/divested-release/-/jobs/7046900191/artifacts/raw/build/noarch/divested-release-20240607-1.noarch.rpm'

On second thought, the Divested repo is a bit problematic so I might replace it with the secureblue copr

How about opening an issue about this on GitHub? Not sure what qubes devs opinion on this is…

I’d like to get your guide working with a debian-12-xfce TemplateVM. I followed everything apart from the trim down script, and the Mullvad app is connecting as anticipated, but there is unfortunately no network connection from the AppVM which has it’s net qube set to the ProxyVM. Any idea why this might be the case?

1 Like

Did you follow this step?

Yes, Local Network Sharing and Lockdown Mode are both enabled as per the guide.

I’m able to ping 8.8.8.8 successfully, but not curl anything, so seems to be DNS-related.

Strange, it works just fine for me on GNOME. Did you try switching DNS servers and switching back? Did you make sure that the systemd service is enabled?

1 Like

Ah, the issue seems to be that systemd-resolved is not present on default bookworm installations. So indeed, dnat-to-ns.service failed to start because “Unit systemd-resolved.service not found”.

From the above Debian release notes:

" Note that systemd-resolved was not, and still is not, the default DNS resolver in Debian. "

How could /etc/systemd/system/dnat-to-ns.service be modified to use the default DNS resolver? Thanks for the help!

Seems like a problem with qubes templating. Can’t you just install systemd-resolved though?