On Tuesday, January 23, 2018 at 4:21:56 PM UTC+1, Alex Dubois wrote: > 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? > > 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)
On Tuesday, January 23, 2018 at 12:44:58 AM UTC+1, Chris Laprise wrote: > On 01/22/2018 04:36 PM, 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? > > > > I have two ideas: > > 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 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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d2a2f40f-d668-492b-9d75-b3dee8349b12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
