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).
1 Like
There’s already an issue about this. Sure, I can ping you on it.
1 Like
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.
3 Likes
An interesting approach I guess could be to make a “Trust modes” “Safe Mode” Qubes extentsion or something. It could have two modes:
- High
- Normal
When in normal, highly trusted qubes would fail to start. When you start a highly trusted qube / screen locker it would show you a prompt: enter trusted mode? And if you say yes, it pauses all other qubes, except untrusted ones. When you close it, it resumes them.
Just and idea.
3 Likes
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
2 Likes
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.
2 Likes
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.
1 Like
It depends on your workflow. I am using disposableVMs for many things. Restarting them is not hassle-free… After a restart, I have to open everything again and login to the services I need.
1 Like
There should be a way to automate that. In fact, there should be ways to automate many things in Qubes (VMs) to make the whole OS more responsive and have good workflow. For example, with Tasket’s qubes-vm-hardening you can then use sudo chattr -i -R .config/autostart to have one or more programs start when the VM starts, so starting a VM leads to all programs/terminals starting as well, saving a bunch of steps.
It shouldn’t be much of a hassle to tack more actions onto the startup procedure. For example, once the browser has started up and loaded its startup pages (whatever you’ve set it to be), have it also automatically log in.
There should be an automation thread for Qubes IMO, and Salt might feature heavily. I really ought to learn Salt.
I’ll get a Tiger Lake -based laptop for testing soon, and to my understanding Qubes (Xen?) won’t be able to suspend that thing, possibly ever. So I need to learn a daily shutdown routine with that machine. I think it’s good for security as well to not rely too much on suspend.
Suspend does seem to create security issues, but those are local issues–i.e. someone needs extended physical access to your laptop. If your installation doesn’t/can’t have Anti Evil Maid, like most people, your risk won’t be significantly higher or lower than before.
Not technical; consume with salt
Since most people who have voted say they never boot their entire system voluntarily (tied with ‘once a week’), how often do people experience the following:
I reboot frequently since I can’t suspend, and I don’t want to leave my computer continually idling for a week, so I can’t really test this.
I think there’s more security issues with having things like browsers running for weeks, even months (like I do sometimes, shame on me…), with all those session tokens etc. around. So I think rebooting routinely is good for overall computer “hygiene”.
It’s just a lazy, bad habit. Now that I’ve been experimenting a bit with this new laptop that cannot be suspended, it’s not really that bad to boot up every morning, do the work, and then shut down. I just need to automate few things at startup. With my normal workflow, I have massive boot up operation, and then I just run as long as possible with everything open, using suspend every night. Not very good. There’s lot of things that can be done. My main work driver (Emacs) can be be configured to restore sessions etc. Now that may be another security issue…
I reckon you should make an investment so that you can reboot more often. Maybe invest in learning Salt?
I shutdown nightly. Color me digitally skeptical, but I like it that way.