If I put an entry into the /etc/fstab, I can mount a network drive. However, this still requires that the qube have network access.
What I thought might work was to add the entries to the /etc/fstab of the template, give the template network access, but then take away network access of the qube based on the template.
This appears not to work. Opening up a shell for the template works fine when looking at the mounted directories, but trying to navigate there in the networkless qube just complains about lack of network.
Another thing I thought of is to create a qube with network access, mount the drives there, then somehow export that directory to the qube without network access.
But, the only thing I found for sharing directories is qvm-mount, which I can maybe try, but I had hoped there was a recommended way to do this out of the box.
Isn’t the firewall in sys-firewall? So, I guess I’d need to clone sys-firewall and create different rules and then use that? I’m not actually sure how to use the firewall to allow mounting drives. Would cifs drives use a specific port or something? Or maybe I could limit by target ip?
EDIT: Ok, I just found the firewall tab in the qube settings. I can limit to a target ip, but first thing I tried was ping and ping isn’t blocked by the firewall and I can ping any ip even if curl appears to be limited. So I guess I’d need to use iptables in the template to block icmp. This is the sort of thing I worry about and is the reason I just wanted to do it the way I originally planned. I used the firewall tab to block outgoing requests except on port 445 to a specific ip. Yet, that still allows ping which means there are probably other things that I don’t know to block. I need a firewall setting that truly blocks EVERYTHING or I will inevitably screw something up.
sys-firewall is an important part of Qubes security; if you don’t use it in this application, you will use it in others. So if you need to learn more about how it works to gain its trust, then I encourage you to do that.
You can see the implementation of your firewall rules by opening a terminal to sys-firewall and: sudo nft list table ip qubes-firewall
In there will be an nft chain for each qube you have running. Find the one corresponding to the qube you care about. It can look something like this:
chain qbs-10-137-0-71 {
ip daddr 167.80.119.8 accept
ip protocol icmp accept
reject with icmp admin-prohibited
}
With this you’ll be able to confirm (going by the example above) that icmp is allowed by default, but that there are no other holes. The third rule is a blanket rejection on everything that doesn’t match the first two rules.
If you want to block icmp as well then I think inserting this into /rw/config/qubes-firewall-user-script in sys-firewall should do it (untested):
nft add rule ip qubes custom-forward ip addr <your qube ip> ip protocol icmp reject with icmp admin-prohibited
Rather than messing about in sys-firewall, it’s easier to use qvm-firewall to set those rules the Qubes way.
Once you have configured the firewall as you want with the GUI in
settings, drop to a terminal in dom0. qvm-firewall QUBE will list the extant rules, with helpful numbers.
Let’s say you have rule 0 setting the restriction to a host, followed
by rule 1 (dns), rule 2 (icmp), and 3 drop.
Then qvm-firewall QUBE del --rule-no 1 issued twice will result in
your desired access followed by a drop rule.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
The way @unman suggests is easiest, as long as you keep in mind the following gotcha: if you delete the icmp/dns rules with qvm-firewall, they will be resurrected if you later modify the firewall rules using the GUI.