Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
Just a heads-up for anyone else reading this thread who may want to try this too and is not aware of this pitfall, a warning before trying. Any mistakes done in the scripts can make the template unable to start applications. For example even if it can boot-up, applications may not start. 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. -- 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/6e9f291e-1660-46cd-98f2-56c13a1354d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
On Wednesday, January 24, 2018 at 8:32:24 PM UTC+1, Chris Laprise wrote: > On 01/24/2018 10:55 AM, Yuraeitha wrote: > > > > > 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. > > I'm going to test the Qubes-VM-hardening service on Qubes 4 tonight to > 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. > > Actually, you don't even need to change the mountpoint, which is done by > 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. > > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 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. -- 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/9268fb67-8353-45da-b418-a760ebc0e2b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
On 01/24/2018 10:55 AM, Yuraeitha wrote: 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. I'm going to test the Qubes-VM-hardening service on Qubes 4 tonight to 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. Actually, you don't even need to change the mountpoint, which is done by 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. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/72a47f39-2576-9fdb-1c62-db6e320604d8%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
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
Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
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 -- 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/cc3ee414-bcaa-191e-2a9a-93ccab11d275%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
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? -- 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/9d1cd503-364a-4658-87cd-a4872b7dbed6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
