I think Spectre/Meltdown attacks are a very advanced threat that I’m not even sure is in the wild.
So no, I definitely don’t. Not near that threat model.
All the passwords I protect in my vault I not too long ago had saved in browser cookies, so this is a sufficient step up in security :'D
And I find it faster than any system I’ve used before also.
I think this deserves to be here:
Above someone mentioned running two separate sets of network and firewall VMs, one to mind ethernet and one to mind wifi. As it happens I did this on the very first day I had Qubes OS; because I didn’t know how to get the system to try to update over a machine NOT named sys-net; I simply made that the WiFi-only machine and created sys-net-ether and sys-firewall-ether. (Now I do know how to do that and so I’m now using sys-net-wifi and sys-firewall-wifi.)
OK, here are a couple of other things I’ve been doing:
Sort of like Phoenix Qubes: When I converted my laptop over to Qubes, I did the default install, then copied my salt files (lots and lots of them!) over. I was then able to set my laptop up much like my desktop, excluding some things that didn’t make sense. (The laptop doesn’t have ethernet capability, for instance, so anything ethernet based doesn’t get installed there.) After going back and forth a few times, I’ve got it to the point where I can copy the entire salt area over, then regenerate from scratch; one file generates two or three others that differ by hardware and the rest goes from there. Almost everything in that directory is read-only. (I have one bash script whose job it is to tell its caller whether a VM should be generated based on which hardware it’s running on.) Alas even Qubes can’t do anything about slower laptop processors and screens.
My email client. Yes, I’m old school, I download my emails into a client program (thunderbird) and HATE having to use webmail when away from my home computer; any Email I send will never, ever be able to go into the “sent” folder on my client; it’s online in what amounts to a “cloud.” But now with my laptop having template VMs identical to my desktop…I can simply back up my EMail client AppVM to a thumbdrive and restore it to the other platform. (As soon as it’s backed up, it gets renamed to MyEmailQube-Backup so I don’t accidentally use it while the “other” machine has the “main” copy.) It takes about fifteen minutes to transfer from one platform to the other, unfortunately, but I can now take my email client with me!
So if I’m getting it right, the advantage of using Phoenix or Salt-regen Qubes is portability and interoperability? Are there other advantages over disposables in terms of security?
I’ve been looking to learn Salt, since it seems to be the key to creative Qubes use, and you might just give me my reason.
Before I was using salt, I was using scripts to set up virtual machines; one for each.
I’m still using scripts, only now they invoke salt. Salt normally operates through “tls” (top level something-or-other) files. One of the things you’ll end up learning is that every invocation has a “target” and it may not be intuitive. To create a VM the target is dom0 (since it actually performs the task); but when you want to install software, muck about with configuration or “dot” files, etc. your target will be the VM itself. Salt will start that VM and execute commands on it. (My scripts could do something similar, but it took some hoop-jumping…I had to run a script on dom0 that copied my other script onto the VM, then dom0 had to do a qvm-run on the machine to tell it to execute the install script.)
So now as I set up minimal templates, it goes something like this: Create Template A (target dom0). Configure Template A (target: template A). Then clone Template B from template A (target dom0), because B is A plus a couple of apps. Configure Template B (target Template B).
The problem is I couldn’t for the life of me get Salt not to immediately clone B from A after creating A (but before A was configured). There was no way to tell dom0 to kindly wait for Template A to finish doing its thing before moving on, not within one tls or sls file anway. It could be done by breaking dom0s task up into multiple sls files, but then…I needed a bash script to manage that.
So I generally run salt from a bash script now. Even so it still has its advantages. It’s smart enough not to install things that are already installed (my scripts were not), and also smart enough to realize that something that is installed now can be updated. (It also integrates well with the Qubes updating scheme; I can get the updater to run my salt states.) So to update a template I re-run the configuration salt formula (I sometimes also run the create one, but since the VM already exists it just resets prefs and features if they have been changed, or changes them if you changed your salt file). Since I was able (with a bit of convoluted variable setting) to get Template B’s configure file to include Template A’s configure file, it will update everything, including the stuff cloned over from A. In fact, I can do this even if A has been deleted.
I was able to copy all of the salt stuff (and configuration stuff that salt installs) to my laptop, and run it there (and fix incompatibilities as they arose). But you could do all that with scripts.
One thing that just flatly doesn’t work with salt is updating the menus. The gui way to do this is to go to the applications tab in the settings window and refresh. (But note that if you do this in a named disposable it will not reasses what’s in the templateVM, only what’s in the disposabel template.) On the command line, qvm-sync-appmenus is the command that should “fix” menus and it works…from the command line. It must be run in dom0. You have to start the VM, then run qvm-sync-appmenus, then shutdown the VM. Setting up a dom0-target salt file to do these three steps simply doesn’t work. The states execute but there’s no effect; the things qvm-sync-appmenus are supposed to affect are not affected. This is another reason I’m still using bash scripts; once I have created and configured my VM, i start the VM, run qvm-syn-appmenus, then shut it down again in the script.
I too replaced extensive scripting with Salt.
I work through the issues that @SteveC mentions by using ordering and
requires in the salt states, and by building hierarchies of states.
It is a good thing to have multiple state files, since it accords with
the general salt approach of modularity and clarity
I think we have discussed the question of updating menus in another
thread. I don’t find doing this any more unwieldy in Salt than using the
command line directly, although I should say that I don’t make much use of
the Menu myself and am only interested in this when configuring for
others.