Thanks for the usage outline @Sven, I’ll give it a go.
@adw @Sven If you can create an issue in the most appropriate GitHub repo and ping/mention me there, I’m happy to write usage docs and open a pull request. (My handle on GitHub is the same as in this forum.)
Restarting VMs is not a time-sink, especially if you use the qvm-shutdown --all and then a qvm-start [VM] [VM] [VM}. This, I expect other users would do quite often (at least daily).
I think this is the default among users–rebooting VMs using the qvm-shutdown --all command and only rarely rebooting dom0, with updates as exceptions. I need to figure out how to fix my suspend.
Is there anything that might help encourage you to reboot or restart your VM more often? Restarting something as exposed as browsers weekly sounds less-than-ideal to me. However, I’m not sure the qubes-app-idle-shutdown script would help here assuming the browser window is continually open, blocking the trigger.
This is hardcore, at least to me, but I can see why it might necessary for some. Wouldn’t running four hours of backup every night wear out your storage devices quickly? (Both backup and original).
This is good advice–something I had forgotten about. Powering up is a pain, but disk encryption is worthless otherwise.
I’d love to see a guide to minimum memory for various VMs, which would be helpful for new, old, and especially aspiring Qubes users since lack of RAM seems to be a common hardware deficit.
Nice. Is Devilspie2 available on dom0?
I’m pretty practical with this, so I don’t always aim for ideal. If I think my bad habits before Qubes… I mean like running the same browser without restart for months (or as long as I could before it choke on its memory usage) on a typical bare metal Linux. This has been a huge improvement.
True. A large part of security IMO is opsec (operational security?), and habit formation is a big part of that. Having formed good habits to the point where not doing them feels wrong is a worthy goal, but sometimes it takes time to undo and replace the bad habits one has already built up (while not forcing oneself), so slow and steady improvement seems to be important for fundamental opsec habits (as opposed to, say, hastily adopting new measures that you then forget and revert back from just as quickly since the habitual foundation isn’t there).
I do use “qvm-shutdown --all” before rebooting or shutting down. I always close all VM before shutting down. Like I explained, I have to reboot from time to time to get rid of the graphical glitch that I experience after waking from suspend.
I think we’re misunderstanding each other. I was talking about rebooting all VMs as a separate activity from rebooting the OS proper, while it seems your situation led you to bundle the two together and treat them as one action.
Yes, the current problem is leading to rebooting the whole OS more often than just rebooting all my VM.
So, although I did understand your question, I didn’t answer it like I should because I am forced to reboot the system to work without problems.
Hypothetically, I think I’d still restart the whole system every few days (partly because of updates and because that’s what I always did).
There’s already an issue about this. Sure, I can ping you on it.
As for the original topic:
Ever since Meltdown & Spectre, I effectively reboot qubes multiple times per day as a side effect of avoiding running sensitive qubes concurrently with untrusted qubes (to the extent possible). Similarly, I try to shut down or pause untrusted qubes before allowing my screen to lock, since I have to enter my screenlocker password in dom0, and dom0 is a VM that runs concurrently with any other VM that happens to be running. See QSB-037 (and subsequent speculative-execution-related QSBs) for details. Although all known patchable vulnerabilities have already been patched in Qubes, security experts generally agree that we likely haven’t seen the last of the general class of vulnerability of which Meltdown & Spectre were the most prominent examples.
I reboot Qubes OS approximately weekly, mainly due to #3964. I also reboot after all Xen and kernel dom0 updates, as a reboot is required in order for these updates to take effect.
An interesting approach I guess could be to make a “Trust modes” “Safe Mode” Qubes extentsion or something. It could have two modes:
Just and idea.
Related
I’d call it ‘safe mode’ if the term wasn’t so strongly associated with something else. I like it–basically it enforces a separation between sensitive VMs and everything else, so sensitive VMs can’t just run concurrently with less-trusted VMs without explicit authorization. It’s another layer of compartmentalization. One problem I foresee is how you separate sensitive VMs from each other, because once we get granular enough (enough categories), we’re back to the old trust labels, but with prompts.
Worth a separate thread or even a Github issue, IMO
With that Github link, are you saying there are issues with starting up, so it’s safer to do so less often?
Nowadays I’m starting to think habits or processes are the one single biggest factor in any security. And with smart technical devices (I’m thinking about Qubes right now), the habits can be enforced, and eventually they are going to stick around. Security that doesn’t stick around is no security, no matter how sophisticated.
Before Qubes, I was doing something similar with complicated SELinux sandboxing. It was nightmare compared to Qubes, which really nails the difficult combination of security and user experience.
I like to think of it like this:
You’re the most wanted person on the face of the planet (literally), so you hunker down in your self-sustaining bunker near the center of the earth. With your ultra-advanced facility, you’re secure from any and everything up to and including a life-obliterating meteor strike–you’re as secure as one can be. However, you just can’t shake your habit of gleefully tearing apart packages that arrive on your doorstep…
Not at all. After around a week of dom0 uptime, I can’t start any other VMs, so I’m forced to reboot.
Memory is not likely to be error free for days at a time, or so I was told.
There is a note somewhere that Linus Torvalds wanted manufacturers to supply only ECC for all Computers, which ran Linux. He stated that memory was not as error free as manufacturers would have the public believe.
In 2009 I bought a Mac Book Pro, and was informed that the Apple Genius people believed a computer should be completely shutdown instead of put into suspend or hibernation.
Old school Operating Systems (large main frames) needed to be rebooted because the buffers would not properly reset. My android phone slows, apparently because of un-acknowledged Notifications. Still that is Android. Early Windows Users rebooted when they went to coffee break or Lunch, as it made the computer run faster.
I am pretty sure I was told that from the very beginning, Linux never had that problem.
But I am usually wrong.