Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
Yuraeitha
For example, to make an AppVM which only preserves bookmarks in /dev/xvdb that normally keeps /rw /home and /usr files, where everything else is swept away upon restarting the AppVM. There are other use-cases than for bookmarks, whatever project one may have in mind.
For those who may need the reference, the Qubes partition read-only and write-access scheme is explained here https://www.qubes-os.org/doc/template-implementation/ Essentially the /dev/xvda is like the template, and /dev/xvdb is like the AppVM.
It may possibly be a bit difficult to split up the path to the firefox files, away from the remaining /home files, and further splitting up the firefox files to only preserve the bookmarks and not the remaining firefox files. This presumably complicates everything, however similar approaches can be seen with /dev/xvdc which holds any modified read-only /dev/xvda files, which are then discarded upon shutting down the AppVM. The other example is how the Whonix AppVM is handled, which only preserves a few things, like bookmarks, and erases everything else. However the Whonix approach while similar, is fundamentally different too, since this process is being handled inside the VM, and not outside the VM.
So the question is, can the borderline between which Linux paths are saved in the read-only partition /dev/xvda and the write-access to /dev/xvdb, be changed in any specific pre-installed template? And further, can everything be moved back to /dev/xvda, without removing firefox folder from the /dev/xvdb, or better yet, only allowing edits to the bookmarks directory only while keeping the remaining firefox folder in /dev/xvda?
Whould splitting of files here require using a similar approach like the one used with /dev/xvda and /dev/xvdc for system-files? Can this be done with current means in Qubes?
Ideas or suggestions on if this is feasible or maybe even undesirable for any unseen reason?
Chris Laprise
1. Change the mountpoint handling for xvdb in
/usr/lib/qubes/init/setup-rw.sh. Obviously, this would be a custom patch
for your own installation.
2. Use a private-filesystem guard like the one I made at
https://github.com/tasket/Qubes-VM-hardening/tree/systemd
The latter gives you the ability to have everything in /rw wiped with
the exception of a whitelist that you specify. This is handled at boot
time just before the normal /rw mount process. It is tested with
debian-9 template on R3.2, current state is beta.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Alex Dubois
Could you have a process to backup your bookmarks in /home/user (i.e. every 10 min)
And have a process on start-up to load them up?
If you are OK to create the bookmarks elsewhere you could create them in a "bookmark vault" and get them pushed on start-up (from Dom0, start bookmark vault, start browsing VM, initiate transfer of bookmarks from vault to browsign)
Yuraeitha
> On Monday, 22 January 2018 21:36:46 UTC, Yuraeitha wrote:
> > The purpose is to narrow down access to an AppVM based on /dev/xvdb, keeping more of the AppVM in the read-only /dev/xvda template partition.
> >
> > For example, to make an AppVM which only preserves bookmarks in /dev/xvdb that normally keeps /rw /home and /usr files, where everything else is swept away upon restarting the AppVM. There are other use-cases than for bookmarks, whatever project one may have in mind.
> >
> > For those who may need the reference, the Qubes partition read-only and write-access scheme is explained here https://www.qubes-os.org/doc/template-implementation/ Essentially the /dev/xvda is like the template, and /dev/xvdb is like the AppVM.
> >
> > It may possibly be a bit difficult to split up the path to the firefox files, away from the remaining /home files, and further splitting up the firefox files to only preserve the bookmarks and not the remaining firefox files. This presumably complicates everything, however similar approaches can be seen with /dev/xvdc which holds any modified read-only /dev/xvda files, which are then discarded upon shutting down the AppVM. The other example is how the Whonix AppVM is handled, which only preserves a few things, like bookmarks, and erases everything else. However the Whonix approach while similar, is fundamentally different too, since this process is being handled inside the VM, and not outside the VM.
> >
> > So the question is, can the borderline between which Linux paths are saved in the read-only partition /dev/xvda and the write-access to /dev/xvdb, be changed in any specific pre-installed template? And further, can everything be moved back to /dev/xvda, without removing firefox folder from the /dev/xvdb, or better yet, only allowing edits to the bookmarks directory only while keeping the remaining firefox folder in /dev/xvda?
> >
> > Whould splitting of files here require using a similar approach like the one used with /dev/xvda and /dev/xvdc for system-files? Can this be done with current means in Qubes?
> >
> > Ideas or suggestions on if this is feasible or maybe even undesirable for any unseen reason?
>
> And have a process on start-up to load them up?
>
> If you are OK to create the bookmarks elsewhere you could create them in a "bookmark vault" and get them pushed on start-up (from Dom0, start bookmark vault, start browsing VM, initiate transfer of bookmarks from vault to browsign)
All 3 suggestions are you guys brought up are really intriguig, I'm pretty excited about this, these ideas are excellent, even better than I hoped for.
I'm using Qubes 4, so I assume I can't give the beta setup a try until or if it becomes available on Qubes 4. But I from my initial understanding I like the extra security it provides, although I've yet to better grasp its full potential. It seems like a pretty cool project you're working on there Chris.
Unfortunately I don't have much experience as a coder either, so I can't make such a script Alex, I can at most read scripts or make simple ones. But it's a pretty good idea as well, it'd be amazing if someone would want to make such a bookmark-manager and contribute it to Qubes. Maybe even take it further and storing the bookmarks outside the VM until a single bookmark is needed? Similar to keeping i.e. KeePassX in an offline VM? Though I imagine that would add further complicity, which is definitely outside my skill-set.
For now I'll try dwell down into the /usr/lib/qubes/init/setup-rw.sh re-mounting suggestion. It's the only one I have the skill-set and current-means to pull off on my own. It's been some long exhausting days, so hopefully I'll get around to try this tomorrow.
I'm currently pondering about how to change the mount points correctly though. It seems like it has similar logic to traditional Linux mounting logic, and when combined with Qubes template/appVM logic, then it seems like I can solve it with some trial and error and exploring-testing, using your post as an initial starting point. I have some leads now, it'll be interesting to look into. I'll post pack on how it goes.
Chris Laprise
>
> All 3 suggestions are you guys brought up are really intriguig, I'm pretty excited about this, these ideas are excellent, even better than I hoped for.
>
> I'm using Qubes 4, so I assume I can't give the beta setup a try until or if it becomes available on Qubes 4. But I from my initial understanding I like the extra security it provides, although I've yet to better grasp its full potential. It seems like a pretty cool project you're working on there Chris.
>
> Unfortunately I don't have much experience as a coder either, so I can't make such a script Alex, I can at most read scripts or make simple ones. But it's a pretty good idea as well, it'd be amazing if someone would want to make such a bookmark-manager and contribute it to Qubes. Maybe even take it further and storing the bookmarks outside the VM until a single bookmark is needed? Similar to keeping i.e. KeePassX in an offline VM? Though I imagine that would add further complicity, which is definitely outside my skill-set.
see if it needs any adjustment for the whitelisting feature to work.
I'll also expand on the (admittedly sparse) instructions.
If it works then its probably easier to add a service and maintain a
single whitelist file.
> For now I'll try dwell down into the /usr/lib/qubes/init/setup-rw.sh re-mounting suggestion. It's the only one I have the skill-set and current-means to pull off on my own. It's been some long exhausting days, so hopefully I'll get around to try this tomorrow.
>
> I'm currently pondering about how to change the mount points correctly though. It seems like it has similar logic to traditional Linux mounting logic, and when combined with Qubes template/appVM logic, then it seems like I can solve it with some trial and error and exploring-testing, using your post as an initial starting point. I have some leads now, it'll be interesting to look into. I'll post pack on how it goes.
mount-dirs.sh, BTW. One example is to change the line that starts
'initialize_home' to:
rm -rf /rw/home-old
mv /rw/home /rw/home-old
initialize_home "/rw/home" unconditionally
...and then cp or mv files from /rw/home-old as needed.
Yuraeitha
Sorry for the delay, it was finally possible to find home-time to play with this (the dread of being on the road too much).
I followed your instructions, and it works beautifully!
The change from "ifneeded" to "unconditionally", is it correctly understood to be the one that freezes the /rw/home folder at the template: /usr/lib/qubes/init/mount-dirs.sh? If so, then I think I understand this part of it now. I might do this to all my templates, it's a pretty awesome trick, many thanks for sharing/helping! :)
My worries are if updates clean up these scripts though. I know it might be an impossible question to answer as anything is likely subject to change whenever, but does updates happen to these files frequently? Will the updater warn if there are changes? (like i.e. it does if there are changes to /etc/fstab in debian templates?).
Have you considered sharing this as a guide on https://www.qubes-os.org/doc/ on this? Of course only if you got the time and interest. Maybe even whether your script adjustment can be implemented as a permanent feature of Qubes templates, and then people only have to move between the folders in the AppVM, and not do anything to the scripts in the template? That'd be pretty neat for those who have a hard time getting to the motor under the car's lid, so to speak. I mean, it's pretty smart, it even works like before if not moving anything between the folders, so people won't even feel any difference if not moving between the folders, I assume.
Will be keeping an eye out for when/if you release the VM-hardening beta for Qubes 4, no pressure though, can wait till/if you have the time/interest.
Yuraeitha
So be very careful to try this on any templates that are used for something else, especially important stuff, like sys-net / sys-firewall, or templates many AppVM's are based on, making it tough to undo any user-mistakes. Recommendable to make a dom0: "qvm-clone template-nr template-nr-clone" before editing anything. Thereby only having to worry about the testing template.