We all know disposables are great since any malware that infects them is destroyed when the disposable is shut down, but what about all the other qubes we use?
One thing I always liked about re-installing my OS is that any hidden malware will be wiped along with the OS.
I am wondering if it’s a good idea to replicate this with your AppVMs and Standalones?
Obviously you have the overhead of having to set up the qubes again to have all your user settings, but perhaps doing this once a month provides a nice cadence while also ensuring that any nefarious things that may be residing on the qube gets wiped.
I occasionally do this, but it’s more for cleaning purposes than anything else. I manually save the directories I want and recreate. I’ll definitely be looking into the new custom persist feature though.
The biggest things I’d think about if I were you are whether any malware is in the data you would be transferring and whether your goals are better accomplished with DispVMs/bind-dirs.
For example, Firefox’s profiles are places malware can very easily hide. If you’re copying those verbatim, then an informed attacker would simply put malware there.
I’d also like to add something I’m looking to implement myself, but will require a lot of work to me due to some nonstandard workflows, but may be easier for you. I’m looking to put all of my storage into either plain block devices or qubes that don’t run anything, and then open everything in DispVMs. Probably easier said than done, and definitely with its own errata (such as the problem of making sure things save), but worth looking into if you can justify the work.
That certainly sounds like a hassle and outside my threat model but it’s certainly the idea that I’m hinting at. The issue with constantly using disposables is the overhead of having to load non-persistent data into them every time. However I would feel re-assured about doing it every month or so
I am mainly trying to protect against unknown threats here with a generic passive threat model (opportunistic malware, drive bys when visiting some random website in an app qube, user mistakes etc.)
I am mainly looking for critques on the idea as maybe I am being overly paranoid here. @parulin I’m thinking mainly of malware that will install to the user’s home dir
The best thing you can do in this case—and the Qubes-recommended way—is to take a moment and really think about your threat model and workflow. Make a threat model if you don’t have one. Then dissect everything as deep as you can/want and separate everything risky into separate VMs. For what you’re thinking, I’d just separate email and untrusted browsing into their own VMs. That’s where 95% of 95% of people’s malware will come from.
By ‘untrusted browsing’ I basically mean to sort out anything you know you can trust, like banking, government stuff, etc. (These are examples of things, and what consists of ‘trusted’ is highly personal. You may not trust your government, for example. Make extra VMs accordingly.) A medium-difficulty/medium-security example would be to separate medical/financial into a qube, online shopping into a qube, email into a qube, social media and other personal accounts into a qube, and other random browsing into its own qube. All of these activities have different expectations for security, sensitivity, and privacy/anonymity, and so are separated into different qubes.
It is straightforward to implement - I use this model almost all the
time. Offline data storage with files opened in disposables - you can
see it salted for multimedia here and
packaged for easy install here
The only issue with what you propose is the risk of carrying the malware
in the data you are backing up and restoring. You can mitigate this by
good separation of activities between qubes, and sensible storage
policies, for example, store data in offline qubes with minimal
installs.
I use disposables for almost everything so I am effectively recreating
some qubes regularly.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
standard one from installation (deleted untrusted - disposable for web is better)
Separate templates for everything that needs something to install or to configure in template (like bind dirs or disposable profiles for firefox)
standard one from installation (deleted untrusted - disposable for web is better)
Separate templates for everything that needs something to install or to configure in template (like bind dirs or disposable profiles for firefox)
What do you use the personal qube for?
I assume you use the work qubes for your day job (if you have one)
This all depends on your threat model. For instance, back when I was still working, my organization was specifically targeted by actual nation state bad actors. Security incidences were a real and persistent threat.
What I did was to compartmentalize my email (Thunderbird) and internet (Firefox) to their own AppVM and then set up firewall rules to match what my expectations were for email, and a local file access monitor for my Internet browsers file system.
My email AppVM could only get to the email server, and nothing else. If I had to open a link, I just sent it to a DispVM for processing.
When Internet browsing, I dynamically traced the file access of the browser, while looking for attempted writes to anything outside the specific areas it should be normally expected to write to. Anything outside of that area and I would trash that AppVM and recreate it from scratch by cloning a prebuilt AppVM with all the tweaks already done. Those template AppVM’s were never used for email/internet and were only there to store the configuration in case I needed to recreate that environment in a hurry.
When I needed to actually save any data from either VM, I would just copy that data to the appropriate vault VM for more permanent storage for that specific project. Bookmarks and contact lists were cloned to those template AppVM’s periodically so that any new instances were kept up to date, this way recreating that complete AppVM environment took only a minute.
Sometimes, I have weak moments. Every now and again, I start my browser in the disposable template instead of the disposable one. Things happen. Classic Layer 0 problems. This is why I try to recreate new AppVMs every now and again. You never know which past failures you might get rid of by doing it. 0:-)
It would be cool to have a way to treat templates differently, like being able to toggle their existence in the UI, in effect disabling the option to start software in them while still allowing updates. For disposable templates in specific, this should remove the menu entries for the template, but not starting random disposables from said template. This is probably a problem for more than a few people.
Unfortunately removing apps from disposable templates menu also removes the app from the apps menu. So it’s too easy to mistakenly open an app from the templates menu (with persistence), when actually intending to open the app in a disposable vm. The indicators that one is in the templates menu are a bit too subtle. Only listing the terminal in the disposable template menu and launching apps from the command line in the disposable vm alleviates the risk, but also removes the possibility of creating a shortcut in the panel for those apps.
Settings on template and in “Applications” tab you remove it from used one to available one.
Then in Q menu it won’t be available/seen so can’t accidentally run it. You can do it with every qube.