QubesOS does not offer more protection against targeted attacks than using VirtualBox on a regular desktop (with whichever OS you want). However, what QubesOS can offer, is easier management of identities, each with it own Tor route.

If you need a lot of identities at the same time and only have one computer, the QubesOS VMs will take less resources and allow to run more VMs at the same time.

Basically, for some rare use cases, QubesOS is easier to use than classical VMs. And as per AviD's law, ease of use can translate to better security.

For most use cases however, QubesOS is harder to use. So YMMV.

The last time (maybe a couple of years ago) I read about Qubes, they said it had too many vulnerabilities, I guess they were all related to the specific kind of virtualization used. Sure, they were patched regularly, but still I read it was considered too "buggy" to be considered "exceptional" for security

Question: if I change the LUKS password, is everything about the old one overwritten? Say, if have LUKS with a very weak password like "pass123", and then I wanted to change it to something really secure, would it be ok? Or would anything related to "pass123" remain in the headers and could be recovered?

I think I had seen a question about this here, I'll try to look it up

@reed On an SSD without trim, possibly

> By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password.

From wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/…

I guess to be on the safe side, you should reencrypt the whole volume

@nobody, interesting. But that would make "changing password" on LUKS useless, because the old one can probably still be bruteforced

@reed Yes it practically is. Changing the password only changes the key encryption key, not the master key itself. If their is any chance of the master key being compromised in the past, you have to reencrypt everything.

@nobody, of course if the master key was compromised, you should re-encrypt everything from scratch (and overwrite the old data first). But I was wondering about the LUKS passwords. I'm not sure what happens when you decide to change it (or maybe in practice that means adding a new one and removing the old one).

However I just found this: newbedev.com/…

I'll read that later though

Also this here on SE: security.stackexchange.com/questions/128993/…

Sorry, please ping me if you answer it. Thank you!

@TheShortestMustacheTheorem allow a legit user to clear the login issue by some other method, such as a email sent to them directly.

And maybe reconsider the idea of just increasing the login attempt time on a user's failed login, as clearly it's not going to work.

1. an attacker likely wants to get into many accounts, so they'll just hit up another user instead.

Increase the login time by IP address

@djsmiley2kStaysInside I see. Thank you very much for this insight. :-)

Thank you all!

@FireQuacker Thanks. So the best would be to combine both solutions?

@A.Hersean Probably? I just found that while checking if the question had been asked on the main site

A smaller site might be able to get away with going by IP addresses only

@nobody If you're referring to the blog discussing Linux security, it's pretty spot on, although I think it's a bit harsher than it should be. Linux can be configured to be extremely secure, but they are completely correct that by default, it has a lot of configurations and designs that are counter to security.

@A.Hersean Yes it does. Qubes uses much more fine-grained protection than Vbox because it isolates individual device drivers. However Qubes is not perfect and has some design decisions I disagree with (such as trusting Xen too much and giving each VM root by default).

@nobody It's not at all useless, but spender (Brad Spengler) is completely correct that Xen has its share of vulns. Using a properly-configured grsec system would be more secure than Qubes indeed, but Qubes is still orders of magnitude more secure than, say, plain old Debian.

@nobody Unprivileged eBPF is a security risk, yeah, and an optimization called JIT compilation for BPF bytecode makes it worse, but eBPF is fine as long as only privileged users can load bytecode.

@nobody And this is the real point. While Linux by default is not great (module autoloading by default!?), you can harden it extremely well if you configure the kernel and build it from upstream.

@reed Only on an SSD. On an HDD where writing to logical sector n actually writes to physical sector n, LUKS key erasure is secure. Look into how LUKS uses "anti-forensic stripes".

@ThoriumBR Rowhammer can be largely mitigated by running ECC memory if you also set it to panic on the first error (boot with mce=0 or set the sysctl vm.memory_failure_recovery=0. And Spectre doesn't cross context boundaries so it's not nearly as dangerous, and really only complicates threat modeling. It's not like rowhammer which cuts through privilege boundaries like warm butter.