Hello there.
I am using Qubes for quite a time now. In this duration I have read documentation, forums, user-groups, devel-groups, github and many blog posts from developers and Qubes-Community for various practices and for daily uses of Qubes. There are many documentation which gives security advices here and there. But there is no consolidated information about most secure practices while using Qubes for daily activities (which I consider okay as it’s difficult to put secure things related to so many use-case scenerio at one place.)
After using Qubes for so many days, I felt that there should be some documentation or forum post or guideline to make your Qubes OS secure in most possible way so that users can avoid some silly mistakes if possible.
I would like to put forth some areas for which secure methods can be consolidated-
- Disp VM
- sys-usb (best ways to avoid infected dom0 while handling devices)
- whonix-ws templates ( is it okay to customize tor browser)
- Opening links and files
- Qubes RPC policies
- Pausing VM
- Shutting down a VM which has attached PCI devices without strict reset (without shutting down PC)
- Using Your jpg or png files as dom0 wallpaper ( should we use screenshots (even for extreme trusted images) or is it okay to send file to dom0 if it’s trusted. or don’t change wallpapers at all)
- Is it okay to send data from ultimate trust to insecure VM (like we do in case of vault to browser VM) or is there any secure practice for that.
Use firejail to sandbox your applications e.g.
$ firejail firefox
The main difficulty here is that “secure in the most possible way” is
almost meaningless.
If you think that your main problem is attack from outside , then you
will build walls, portcullis, murder gates, only to fall victim to a
poison ring.
If you get in a taster, trusted chefs and handlers, secure your
property with high end cameras, then you may still fall victim to the
Bolivians swarming over the walls.
Seriously, the most important thing is to help people to identify
where the attacks may come from, and what the likely threat is. And
then you can start to produce relevant advice.
Sometimes the most secure position you can have ( and that provides the
greatest anonymity) is to ditch Whonix, Qubes and your smart Purism
laptop, and get a battered old lenovo running Windows 7.
@tasket has some useful stuff here:
Ok, I would love to have some in-depth discussion about mentioned topics here and if there would be some genuine reasons to update doc, I will submit PR’s, I think.
First of all this is something from device handling-
"Some devices do not implement a reset option. In these cases, Qubes by default does not allow attaching the device to any VM. If you decide to override this precaution, beware that the device may only be trusted when attached to the first VM. Afterwards, it should be considered tainted until the whole system is shut down. Even without malicious intent, usage data may be leaked.
In case device reset is disabled for any reason, detaching the device should be considered a risk. Ideally, devices for which the no-strict-reset option is set are attached once to a VM which isn’t shut down until the system is shut down."
So I wanted to ask that if my sys-usb use my pci devices (usb controllers) with no-stict-reset then is it mandatory to shut down laptop after using a block device like sda1 to attach to vault and after detach and removal from PC. And if I don’t shut it, I shouldn’t shut down my Vault VM? Or this paragraph is meant only about that we shouldn’t shut down sys-usb VM.
And what is the real meaning of usage data may be leaked?
I like that idea. But perhaps if people want to go in-depth, it may be easier to break each topic into its own post and link it back there, than to be following multiple conversations in the same thread 
I think I will split up. thanks deeplow.
Btw, there’s also:
There’s a module for the German security standard IT-Grundschutz which describes standard practices for using Qubes in a reasonably secure way:
[https://github.com/QubesOS/qubes-issues/issues/5976]
Currently, this module is in a draft state, but I expect it to be soon published as a user-defined module on the IT-Grundschutz website.
@unman: Uhm…I just saw this. I would have phrased it exact in the opposite way: The most secure position would be not to use Windows whatever version, but maybe I miss here something, or misunderstood. Could you elaborate on that specific sentence. I would highly appreciate it.
The sentence you’ve pulled out should be read in the context of my
post.
My guess is that you are focussed on one,(possibly unexamined), set of
assumptions. It may be that Qubes provides the best solution given those
assumptions, and that some of the hardening measures referred to will
help in your circumstances.
My point is that “the most secure position” will depend entirely upon
what situation you are in. That is where the analysis has to start.
A pretty Purism laptop, with a nice Qubes sticker, will attract
(unwanted) attention. If you want to clear quickly you’re better off with
a plain laptop.
The best physical hackers I know don’t stand out. They don’t attract
attention: they “fit in”. Of course, this will vary from assignment to
assignment - accessing a datacenter calls for a different look from
entering a bank. But in neither case will a Guy Fawkes mask help.
If you are entering a closely monitored situation, then it may be that
the best thing you can do is fire up Windows, and spend your time on
YouTube and Reddit. Using Whonix and Tor will attract attention.
You hide your comms in Reddit or Instagram, just as your traffic is
hidden amongst those streams.
Thanks for taking the time to elaborate.
But still, there is another way: VMs can be configured for any possible situation; meaning look and feel, how they are seen from the outside. You are right the best cover is to fit in, but that doesn’t mean that one actually has to use all that bad stuff, it has to look like it that’s all. If in the field, in a high risk environment, the best is to not have any IT equipment. Software and data should be encrypted and stored somewhere on a public reachable server. That’s where Tails fits in for example. You don’t carry any information with you around; never.
Over 20 years experience. Does that count? 
Thanks for taking the time to elaborate.
But still, there is another way: VMs can be configured for any possible situation; meaning look and feel, how they are seen from the outside. You are right the best cover is to fit in, but that doesn’t mean that one actually has to use all that bad stuff, it has to look like it that’s all. If in the field, in a high risk environment, the best is to not have any IT equipment. Software and data should be encrypted and stored somewhere on a public reachable server. That’s where Tails fits in for example. You don’t carry any information with you around; never.
I would like to see qubes “seen from the outside” that resemble (e.g)
windows 7.
Over 20 years experience. Does that count?
:unamused_face:
No
Relevant:
Possible source of miscommunication due to ambiguity:
- Physically seen (e.g., shoulder surfing, cameras, X-rays)
- Virtually seen (e.g., user agent spoofing)
There are complete themes that make your Linux installation look like Windows XP / 7 or Mac. A bit of searching you should find them.
But I wouldn’t recommend to hacking or examen leaked documents in restaurant, pub, or Internet cafe.
Na, then…why I’m not surprised?
Thanks. Looks interesting.
Correct!
One possibility is to make your sys-usb qube disposable. Upd: in 4.1 it’s just a tick during the installation. In this case, malicious USB devices can only compromise it until reboot. Same for sys-net and (maybe) sys-firewall.
To add to this, restarting sys-net (and hence the whole network VM stack) before you do anything sensitive would put the disposable nature of the stack to good use.
A few hardening tips:
For the Whonix VM’s, you can enable AppArmor by just changing the kernel parameters in the Qube settings.
For more VM hardening, you can install Linux Kernel Runtime Guard(LKRG).
For Whonix and Debian VM’s, this is made real easy by Whonix(note that Whonix recommends using a VM kernel, but for me it works fine with the default kernel supplied by dom0):
More instructions: