I’m in the process of migrating my desktop to QubesOS. I’ve watched the project from the sidelines for several years and have really been impressed, it’s time for me to dive in.
I’ve read through the relevant documentation and discussions that I have found, and am a bit hazy on a few points. I’ll try not to waste the communities time with my beginner questions any more than I have to, but I’d appreciate some input. For reference I am experienced with Linux and networking, not with Qubes.
I have a NAS on my LAN, that’s hosts my files, I currently have them mounted with NFS on several systems and would like to access certain shares in some of the Qubes, and other shares in other Qubes (I suspect NFS is best, but open to other options)
For instance a “Media” Qube that can access the videos and photo share and a “Financial” Qube that can access a share with financial documents.
Should I mount these inside the Template OS? Or can I isolate that connection in a block device(s?) that I allow only the designated Qubes access to the assigned shares.
What approach is recommended, or have I misunderstood some concept?
You could put the required mount commands in the /rw/config/rc.local script in the application VM (ie. “Financial”, “Media”, etc).
Note that if you want to use NFS, you will probably need to install the NFS client utilities into the template VM that your application VM’s are based on.
Security disclaimer of NAS usage across multiple qubes
Leaving here also a security disclaimer that auto-mouting network shares does creates a centralized point of entry for your devices. There is a reason why qubes doesn’t have the (convenient) share directory across qubes (like virtually) and instead employs a much more tedious process of copying. So only proceed if you understand how this may degrade your Qubes security.
If you’re using nfs share in some of your AppVM, how can you limit that share to a user existing on the nas? Till this time if i wanted to share a nfs folder from my nas, i’ve mounted it without a nas’s user. For example a fstab entry of mine: ip.address.of.nfs.server:/path/to/folder /mount/point/on/the/os nfs default,nofail 0 0
It would be nice if you could write about it, or linking some tutorial. I’m using a synology nas as nfs server.
In synology, I don’t know of a clean way of controlling UID/GID’s. So the first step is to create the users, groups, folders, shares and permission structure that you want on the synology server itself, and it will assign UID/GID’s through it’s own internal mechanisms and store them in it’s own internal database. I won’t go into setting up synology or NFS sharing further as that is covered extensively elswhere.
SSH into the synology server, and find the UID of the use you are using for the AppVM. id <appuser>
In the TemplateVM you need to install nfs-common, then shut it down and (re)start the AppVM. For Debian that might be sudo apt-get install nfs-common
Inside the AppVM, edit rc.local, that might look like, sudo nano /rw/config/rc.local and add something like the following:
usermod -u 1026 user // The UID from synology
mkdir /home/user/nas // Where you want the NFS folder mounted
echo '' >> /etc/fstab
echo '#The following line is added at boot by the /rw/config/rc.local script' >> /etc/fstab
echo 'mynas.rockwest.org:/volume1/ /home/user/nas nfs rw,_netdev' >> /etc/fstab
mount /home/user/nas
This does a few things everytime the AppVM is started:
It changes the UID of the AppVM user to match the one assigned within synology, so that permissions line up as expected.
It creates the folder in the AppVM.
It adds the NFS mount command into the /etc/fstab file
It mounts the NFS folder inside the AppVM.
Now because of the way that I understand NFS works, it is relying on the client (the AppVM) to control user privileges. So if the AppVM is compromised, and the the attacker can change the UID to any arbitrary user, then I imagine they could access files as those other users on the Synology NAS. I am uncertain as my knowledge of NFS security get’s fuzzy here. I suspect kerberos may be involved in securing against this, but it is outside of my expertise.
Thanks! I think i’m gonna play with it in a virtual synology. If there would be any question, may i ask from you here in the topic?
Now i only added some mounts in the rc.local itself, no fstab and without any UID or GID, just as i did earlier on other system. Is it a better approach as you did with echo-ing to the fstab?
There is an option in synoloy for the NFS service: Apply default UNIX permission, whatever that means.
By the nature of qQubes /etc/fstab gets clobbered in the AppVM’s each restart. Hence the rc.local script.
You alternatively could modify /etc/fstab in the TemplateVM and give all associated AppVM’s NFS access. Depends on how you are using Qubes.
I recall running into some issues, specific to Synology’s(broken) implementation of Unix permissions. However it’s been too long I don’t recall, and may have since been fixed.
You could try mounting the NFS folder as a specific user and see what happens. Either with the /etc/fstab in the templateVM or in rc.local of the AppVM. I tried and failed and came up with this solution. I think there are some security issues with it, however once it started working I moved on too other problems. Let me know if you find a better way.
