Recommended way to force-disable networking?

Assume one creates a minimal template holding only software they need in their vault (gpg, password manager, file manager). AppVMs based on this template should never have networking, even if accidentally misconfigured (given the default sys-firewall netvm for example).

What’s the correct Qubes way (won’t be overwritten with template updates etc) to enforce this?
I assumed it would be a rc.local script in template /rw/config which forces down networking or an IPTABLES ruleset drop on all chains?

@BenT just make sure the respective template doesn’t have the qubes-core-agent-networking installed?


Is there anyway that package could get pushed through during an update?

Does the update mechanism have any ability to detect what is ‘supposed’ to be there that isn’t? Or is it simply just the packages for deletion / update that are sent through.

Also any chance that package itself could get updated in the future which would then re-add it to the template?


I wonder if file transfer / secure copy and paste (RPC services) will work without that package.

The primary method for making sure a qube is offline is it’s NetVM property. You want a qube offline? Make sure there is no NetVM assigned.

Then set your default_netvm to '' like I do. That way no qube ever gets accidentally connected, but you have to actually assign a NetVM to bring it online.

I regret posting this. This is not a recommended mechanism to make sure a qube is offline. It might be one of several steps one could take to calm anxieties or to just have a minimal template that only contains what is needed.

These are RPM / APT questions. I don’t know the answers to a certainty, it probably depends on the package maintainers. Maybe someone with a deeper understanding of packet management could enlighten this point.

Again: if the NetVM property is set correctly it won’t matter.

Yes, because they go over qrexec and NOT the networking stack.

1 Like

In Debian you pin the package with priority -1 -
Create a file in /etc/apt/preferences.d/qubes-core-agent-networking

Package: qubes-core-agent-networking
Pin: release *
Pin-Priority: -1

From the man page:

How Apt Interprets Priorities
Priorities (P) assigned in the APT preferences file must be positive or negative integers. They are interpreted as follows (roughly speaking):
P < 0
    prevents the version from being installed.

Pinning is a Debian technique that it’s worth learning.

In Fedora, I believe you can use the excludepkgs parameter in
/etc/yum.conf in the [MAIN] section, to the same effect.


I’ve never heard of any package being “added” to a minimal template without the user installing it. I’m not sure how or why that would ever happen. If it were to happen, I’d probably regard it as a security bug. Then again, I’m no expert, and my expectations might be misplaced, so I’m always open to learning more.

1 Like

I’ve never heard of a package being removed from a template without the
user deleting it, and yet the Forum regularly contains just such reports.

With the interplay between package dependencies and user
inattention it is not inconceivable that a package could be “added”
to a minimal template without the user actively installing it.

The steps I suggested will prevent this.
Similarly I advocate that users of Debian testing templates mark hold
Qubes packages to avoid them being removed inadvertently.

1 Like