Disable Internet Access on Vault Even When NetVM is Provided

General Discussion
1

Hi,

The vault is supposed to be a secure, offline qube for sensitive data, and by default, it has no netvm. But if I accidentally or intentionally assign a netvm to it, it can connect to the internet. That doesn’t feel secure enough for a “vault”, it’s just a VM that’s offline until you give it a network.

Shouldn’t it refuse internet access even if a netvm is added? Maybe the system could at least warn you when assigning a netvm to vault, like it does for templates.

That’s my feature request! Meanwhile, I’ve been trying to lock it down myself.

First, in vault’s VM settings under “Firewall rules,” I set “Limit outgoing connections to …” to 127.0.0.1, then assigned a netvm to test. The browser couldn’t access the internet. But then I ran ping 8.8.8.8, and the pings went through. That’s unexpected, limiting outgoing connections to 127.0.0.1 should block external addresses like 8.8.8.8.

Is this a bug in Qubes’ firewall, or intended behavior? I’d love to understand why it didn’t fully work.

Next, I set rules inside vault. I created /rw/config/nftables.conf with this to drop all traffic:

flush ruleset
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy drop;
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

I made it persistent by adding this to /rw/config/rc.local:

nft -f /rw/config/nftables.conf

I also made rc.local executable since it was empty before. Was that needed, or is it executable by default?

After restarting vault, I tested ping 8.8.8.8 again. Packets dropped and ping failed. It seems to work, but is this enough? Are there side effects to dropping all traffic?

I’m still curious why the 127.0.0.1 rule in VM settings didn’t fully block pings.

Also, if I set the same “drop all” rules via qvm-firewall instead of inside vault, would it work the same? Which is better, qvm-firewall or local nftables?

Then I wondered: What if I remove network capabilities entirely with:

sudo modprobe -r xen_netfront

And persist it in /rw/config/rc.local? Simpler way to kill the network, right? But what’s the downside?

Well, that’s a bunch of questions in one post, but I’m really looking forward to your answers!

Thanks a lot in advance!

2 Likes
2

Correct:

Treat the default application qubes as generic labels, not as qubes with special functionalities.

2 Likes
3

you do not need to limit to 127.0.0.1, this is not using networking.

it’s a limitation of the firewall GUI settings, it’s written down at the bottom of the window, which also tells you to use the command qvm-firewall in dom0 if you want to block icmp (ping) and DNS.

well said :arrow_double_up:

3 Likes
4

Thanks for the response! I do treat the default qubes like vault as generic labels, I got that from the documentation and totally understand they’re just starting points. it was more about “what it could be” since I mentioned it as a feature request.

There should be a default offline VM with hardened security, something that, at the very least, warns the user if they try to attach a netvm to it. That way, it’d better match the “vault” name and protect against accidental slip-ups.

Got it, thanks for pointing out the GUI limitation.

So this is a limitation, but is it set to stay that way, or are there any plans to fix it down the road?

I’m also still hoping for input on my other questions: I set rules in vault’s nftables to drop all traffic, would setting those same rules in qvm-firewall be just as good, or is one approach better? And if I go further and remove network capabilities completely with modprobe -r xen_netfront, what’s the downfall? Could it break anything critical? Looking forward to your thoughts.

Tthanks again!

2 Likes
5

Hm…maybe create a vault VM using minimal template and do not install qubes-core-agent-networking?

2 Likes
6

My problem with most of these mitigations is that they’re under the control of the qube, so they can’t protect against accidentally giving network access to something “nasty”…

What I’ve thought would be a nice feature is a second special case of network VM, which is “Forbidden” - like “None”, but which even Dom0 cannot change at runtime (or at least not easily.)

That would be good for uses like Vault, and also for my default -disposable-NoNet, which isn’t my real default disp, except for some sensitive AppVMs.

I’ve been there… just about to give full networking to the wrong qube, only caught by a lucky double-check.

3 Likes
7

Well, you can of course take actions to reduce the risk of an accident,
but you can’t really preclude yourself from intentionally enabling
network access to a qube if you really want to.

I wouldn’t bother handling it from within the appvm or template.
Whatever you do there would result in a setup that’s harder to maintain
and that nonetheless could be undone in case the vm gets compromised in
those 5 minutes of network access you gave it a while back.

One idea is to setup a firewall with the qvm-firewall command rather
than the using the GUI. If you run “qvm-firewall vmname” it will list
the current rules and (assuming you didn’t change them already) you’ll
see that it allows the use DNS and ICMP (this is why ping works, these
rules are not shown in the gui). Just delete them with “qvm-firewall
vmname del --rule-no x” with x being the rule number as shown by
“qvm-firewall vmname list”. Then add a single rule that drops
everything with “qvm-firewall vmname add action=drop”

Even if you accidentally set a netvm to your appvm, you would also
need to manually overwrite this qvm-firewall rule.

3 Likes
8

This is the way.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
9

Using qvm-firewall is better since the rules are set outwith the
qube.
Instead of “removing” network capabilities, do not install them in the
first place, as @absent suggested.
If you rely on any configuration made in the qube, there’s a chance that
some actor could reverse that change.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
10

Thanks for the idea! Using a minimal template and skipping qubes-core-agent-networking could work, but it’s not ideal for everyone. Minimal templates are a bit of a hassle, you’d have to install a bunch of extra apps to make it usable, especially since people rely on offline vms for all sorts of offline tasks. Fedora, on the other hand, comes with a lot of pre-installed tools, so you can just strip out the network stuff and be good to go without the extra setup.

That said, I’ve got a follow-up question: if we don’t install (or remove) qubes-core-agent-networking, will qvm-copy still work for moving files in and out?

Appreciate the input! I get why qvm-firewall might seem better since the rules sit outside the qube, managed from dom0. But here’s my thought:

If an actor’s already inside an offline qube and able to reverse internal nftables settings, couldn’t they just as easily mess with qvm-firewall too? I mean, if they’ve got that level of access, the game’s kinda up either way, right? Or am I missing something?

1 Like
11

I overlooked something when I replied earlier: not installing network capabilities is tied to the template, not the AppVM. If I skip network capabilities in the template (e.g., by not installing qubes-core-agent-networking), it can’t connect to the internet to install software, which defeats the point of a template for me. I’d rather keep the template functional and handle the network lockdown in the vault AppVM itself.

This sounds promising, thanks for laying it out! I ran qvm-firewall vault and sure enough, it lists default rules allowing DNS and ICMP (explains why ping worked despite the GUI’s 127.0.0.1 limit). Deleting those and then adding qvm-firewall vault add action=drop seems like a clean solution. It’s simple, takes just a few steps, and since it’s managed in dom0, it can’t be undone by someone without dom0 access, as @unman already mentioned it. After wiping the old rules, that single drop rule should block everything, right?

1 Like
12

Generally I prefer a minimal template, but if you do not,
clone the existing full template of your choice, and remove
qubes-core-agent-networking from the clone.

Yes.

qvm-firewall is set from dom0 and enforced on the upstream qube.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
13

Templates use a proxy mechanism to install and update software. There is
no requirement that they have qubes-core-agent-networking installed, and
generally they should not be using “network capabilities”

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
14

When I tried to remove qubes-core-agent-networking with dnf remove command, it also wants to pull out a bunch of important packages due to dependencies. Even using --no-autoremove option to avoid that, it still removes qubes-vm-recommended. The dnf info description for that package says:

Installing this package is recommended to have full functionality available in Qubes VM.

That makes me hesitant, losing “full functionality” doesn’t feel right for any qube, even if it’s offline. Is there another way to strip out networking without losing these key packages?

1 Like
15

the qube firewall rules would not be used if the netvm is sys-whonix or a custom made qube providing network. sys-whonix is not able to hold firewall rules of consumer qubes

1 Like
16

So, if a user qube’s netvm is sys-whonix, any qvm-firewall rules set for that qube might be ignored because sys-whonix doesn’t support that functionality, but internal rules should still work, since they’re enforced within the qube itself. Right??

1 Like
17

exactly, if you need to use firewall rules, just add some disposable qube providing network (like sys-firewall) and put it behind sys-whonix and use this one as the netvm of qubes that should have firewall rules but using sys-whonix.

1 Like
18

Why make it that complex? Why not just add an nftables rule inside the offline qube itself from the start? I’m not talking about adding rules after someone accidentally assigns a netvm to an offline qube, but setting it up in a fresh offline qube right away. If the nftables rule (e.g., dropping all traffic) is already there, it should block internet access even if a netvm gets added later, and it can’t be bypassed unless the user explicitly changes those internal rules. Right? Seems simpler and more direct to me. Am I missing something?

1 Like
19

You first came up with a problem that does not really exist in the first place.

I provided some insights about sys-whonix although it’s a bit off topic, just to be sure everyone is aware of this specific limit.

Your internal qube firewall rule may be good enough, but it would be better to run a script on dom0 verifying every minute that the qube has no netvm and put it offline and send a warning notification if that ever happens.

3 Likes
20

Sorry if the post sounded aggressive, this is absolutely not the tone I wanted. I’m not a native English person, this kind of stuff is not easy to get it right.

3 Likes