What extra layers of protection should I add for better security on Qubes OS 4.3?

What have you installed and/or configured on your qubes os thats proven to help you be more secure from all threats imaginable? I have a post quantum double vpn that routes traffic through whonix. Is there more that I can do?

4 Likes

It depends on your threat model, but if you are specifically looking for security outside but still related to Qubes OS, I can publicly discuss about it.

4 Likes

I’m using this setup that’s my own repository and i use this setup everyday

  1. I install every packages over tor by using tor+https
  2. I use qvm-firewall rules for my vm and allow only https, http, dns trafic and tor traffic everything else is dropped like IMCP traffic (ping etc…)
  3. I fully removed AI , Wallet, Telemetry in brave-browser the browser is “clean”
  4. I use my own apparmor profiles to deny access to a lof of things the browser can’t access the machine-id , root filesystem , etc…
  5. I separate each part of the browser in the apparmor profile to increase the security of the browser ex : brave-crash don’t have the same permission as brave-sandbox
  6. I’m using the Xorg apparmor profile to increase even more the security of the VM and there is also the “tor service” profile provided automatically by apparmor in the last version
  7. Nautilus doesn’t have access to internet in my apparmor profiles , qubes features like move files between vm doesn’t have access to internet too you can view the content here
  8. When i open a editors or pdf the pdf apps doesn’t have internet access and pdf apps can’t access to root filesystem (i only do a profile for okular and mupdf because they doesn’t support Javascript and it’s good for the security)
  9. In whonix i’m using the Xorg apparmor profiles
  10. I removed systemd-timsync in sys-net in my opinion it’s insecure. In favor of a ntp service that support nts protocol like chrony by default Qubes should do something like that. It would be great in the future if Qubes provide a mechanism similar for time sync Tails - Time synchronization
  11. In sys-net i’m using a encrypted DNS resolver
  12. I also have a script that randomize the hostname at boot for template, appvm, dispvm
  13. When i browse internet i make sure to disable Javascript in ublock origin i only enable Javascript for website who really need JS
  14. I minimized debian even more to reduce the attack surface thanks to @qubist
  15. My template only have browser installed each template are using their own browser : ex brave-temp, mullvad-temp etc…
  16. My appvm boot with the same kernel hardening from secureblue Kernel arguments | secureblue

For users reading my post you should only install ublock as extensions in your browser https://discuss.privacyguides.net/t/zero-day-clickjacking-vulnerabilities-in-major-password-managers/30278

I think i’m the only user going so far in term of security but i honestly can’t see how i can be hacked or get malware. My setup is really overkill

7 Likes

Related:

5 Likes

yes please

1 Like

Okay, a few augmentations to Qubes OS security benefit from firmware and hardware (root of trust), particularily Coreboot, an open-source boot firmware. Qubes-certified hardware requires Coreboot among its certification criteria, but leaves the rest of the Coreboot payload implementation details up to the manufacturer. Currently, the situation is split into two mutually exclusive pathways:

  1. Secure Boot
  2. Measured/Sovereign/Verified Boot

@maltfield provided a detailed analysis of the benefits and tradeoffs of each approach in a blog article:

Here are additional related topics:

Currently, the latest in Secure Boot development is Dasharo TrustRoot, and the latest in Measured/Verified Boot development is Flashkeeper:

7 Likes

I also forgot to mention about USBGuard, which is within dom0:

Currently the policy is permissive and has an open GitHub issue:

3 Likes

I think i’m the only user going so far in term of security but i honestly can’t see how i can be hacked or get malware. My setup is really overkill

Yeah its overkill you made everything overcomplicated. You are in Qubes OS but your setup feels like you are doing hardening like you are in traditional linux. You should learn to seperate your activities inside Qubes OS by doing that you can significantly reduce the complications you made.

i honestly can’t see how i can be hacked or get malware.

All those steps you mentioned covers only basic hardening i don’t even call it as basic its should be named as very basic :slight_smile: you made very basic hardening this much complicated. You setup has too many loop holes for your vm to be infected.

The number one main mistake you are doing is relying too much on apparrmor and believing it protects you by creating all those apparmor profiles instead of relying on apparmor try to seperate your activities. apparmor profiles can by bypassed keep this in mind.

Read this docs its has tons of useful information

4 Likes

The best hardening I’ve seen on the forum. God-like level of protection

3 Likes

yes please.

1 Like

This setup only seem to improve security. But makes you extremely easy to track. When you enable js the sites which require it fingerprint your vm. What software it has, what “hardware” it has and so on and so forth. A plain vm with only browser installed will be extremely unusual for pretty much everyone on the internet

2 Likes

That’s interesting i would like you explain me this

I guess you was right CrackArmor: Critical AppArmor Flaws Enable Local Privilege Escalation to Root | Qualys i really think i will stop using apparmor and i’m going to use SElinux only and learn how selinux works

2 Likes

Other than what I have already mentioned above, it is possible to compile your own Linux kernel in dom0 to replace the default VM kernels:

Distribution kernels are designed to be compatible with a wide variety of hardware, but at the cost of increased attack surface due to the amount of modules required to support them. In comparison, compiling your own kernel for your Qubes OS-supported hardware significantly reduces the available attack surface, but requires understanding the various configuration options available (GCC vs. Clang, ThinLTO vs. Full LTO, etc.) along with testing before deployment.

See also:

  • https://madaidans-insecurities.github.io/guides/linux-hardening.html
1 Like