So one question remains in regards to these disposable VMs.
Right now I’ve got multiple applications isolated into their own AppVMs which is not ideal due to the persistence of the home directory. At the same time there is some desire persistence, so I don’t have to log and reconfigure an application for example.
I did get a link from someone before for disp browsers linking bookmarks back to the templateVM which is good, but but some things like discord/matrix (as I am trying to work out an arrangement to move my HTB CTF team off Discord) I don’t necessarily want to log into over and over again.
At the same time, I don’t want to store credentials or sessions in the same template as everything that is ran as disposable.
This leaves cases like a thunderbird client, discord/matrix, session/signal desktop and having to log in every time.
So, is there another github repo for a qubes app that handles stuff for storing sessions/mail profile data in a manner that calls upon that data when needed for disposable VMs? For example, running thunderbird will pull the necessary data without exposing it to other running dispVMs by means of just having them saved in a template?
Based on the glossary, it would appear isolating as AppVMs is what the AppVMs are for. However, since the community generally is on the same page as I am, I imagine someone has had this idea before.
I’m thinking I may just keep everything disposable and just deal with the login hassle tbh, the safety outweigh the inconvenience.
There is quite a bit to unpack that’s certainly a step further than the previous questions. Do you mind if I move your last post to its own thread? I think it will benefit from distinct viewpoints, and with an appropriate title of its own it should be more visible to more folks.
In the disposable template set a service called in /rw/config/rc.local -
this will run when the disposable starts up. The aim is to pull in the
files/directories you need, and move them to the right place.
You can define a systemd service to run at shutdown, using Before=shutdown.target in the Unit stanza. Again, do this in the
disposable template, although you could do it in the template.
The qrexec policy will deal with parameters:
usually it looks like this: service * source target action
But you can set an argument: service session source target action
And then handle that session parameter in the qrexec script, to make
sure you get the directory in to the right place.
I hope this gives you some idea of one way forward - there are many
routes you could take but this is simple.
Remember that you can use bind-dirs in the disposable template to make
sure that systemd infrastructure is set up and working in the
disposables if you do not want to set this up in the template.
If you need help with any part of this, just ask.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
That’s because the edits don’t make it to the mail version of the forum after the first 10min @onisec, it’s a thing to have in mind. Depending in your edit, it may be worth (or not) making a comment as a new post.
A method I use for a few places I have some trust in, is to create a DVM template especially for that site. I run it (the actual template) once to log in. Then from that point forward I run the DVM, and it starts with me logged in already. It’s probably not the most secure method in the world, but for frequent sites I don’t need a ton of security on, it works. (I would NOT set up online banking that way, for instance. You damned well should have to enter your password every time.)
It’s important, though, to make sure you never go anywhere but that site when running the template (and probably not a good idea to “wander” even in the DVM). But if you ever forget and do wander while running the DVM template, it’s quick to regenerate the DVM template and then just log in on it again.
If you do this, any attacker will see a machine that has done nothing except visit that site. They could conceivably get your password, I suppose, but that’s a risk no matter how you do it.
The method has its plusses and minuses, but to me in some circumstances it’s an acceptable balance between security and convenience.
If you ever, down the road, get into “hardening” firefox–which should be done in the template VM, as opposed to the DVM template–you’ll have to set the DVM template up to not wipe cookies that have to do with the site.
One of the sites I go to with this method logs me out frequently; I have to start the DVM template and log back in again. Eventually the DVM template will remember that I’ve opened it up and logged into the same site dozens of times. Well, if/when that bothers me I can regenerate the DVM template and start afresh.
Oh, and since you’re new, you might not understand the distinction between running the DVM template vs. the DVM. A DVM is based off a special AppVM; when you fire it up the system essentially combines the template VM with the AppVM and opens up a one time virtual machine.
That DVM will likely be named something like disp1234, but it is also possible to create a named disposable, one that has the same name every time. (sys-firewall is probably a named disposable on your installation.) This is handy but can be very confusing for newcomers…especially with the naming convention sometimes used where both a named disposable and its template might be named ending in -dvm.
Anyway, let’s ignore named disposables for now.
It’s possible to run the special AppVM itself without it spawning the disposable virtual machine (it’s generally kept way down in the xfce menu to avoid having it be run by accident). If in doubt look at the title bar of the window. If it has the name you gave your DVM template, you’re running the template and anything you do will persist even the next time you run the DVM based on the template–this is how I get a disposable to remember I am logged in on some site.
(I name all my dvm templates ending with “-dvmt” so I know it’s the template I am running. When I set up a named disposable, the name ends with “-Disposable”. So any DVM running on my system will either be named disp1234 or have a name ending in “-Disposable”.)
I am myself fairly new to Qubes (about a year and three months) and I am not a security expert. If what I am describing here is in fact egregiously bad practice, then by all means I hope someone will speak up.
Not a bad enhancement. Will try tinkering with it. Thus far I’ve been policing myself from “wandering” but in some cases I let myself go to a related website. (E.g., salt’s website for a qube that visits here.) Certainly you could set up this solution to let that happen.
Just wanna follow up and let everyone know I haven’t forgotten this post, I’ve just been slammed with work and getting set up, just got a VM built for handling my github repos/domain. Still got some other things that I will need to prioritize over this, like handling VPNs for a CTF, but you all have given me quite a good bit to go through and I’m sure that will take time to be diligent and methodical in applying the knowledge you’ve shared.