I have a bad habit of not rebooting. I use disposable appvm’s for many things, so I do restart my browsers maybe weekly. Should probably do it daily.
Basically only when I’m forced to. I suspend my machine every day, and sometimes it just happens that Linux fails to resume (maybe once every two months or so). Instead of resume, it reboots. That’s my restart . Another case is when I’m away for longer time.
The problem with restarting is in the way I work. I like to keep 8-9 appvm’s running various applications all the time. I just hate to start them up, arrange things back to my taste etc. after reboot.
@turkja you could either follow @unman’s KDE recommendations and use
Activities for that or hook up a bash script under XFCE’s “Application
Autostart” along with some Devilspie2 for positioning of the windows on
screen(s) and in different workspaces.
If you like KDE you should go with that. I tried many times to become
friends with it but always return to XFCE. Couldn’t tell you why.
Maybe because I have everything already setup exactly the way I want it
using the above method and replicating it in KDE is just too much work
(but probably less work then doing what I did from scratch – plus it
requires basic scripting skills).
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.
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).
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:
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.
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
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.
. Another case is when I’m away for longer time.