Hello,
Does QubesOS implement features like hardened malloc, and Libc?
Also is it possible to create a ‘duress’ password’ which wipes the contents
of a hard drive upon entry?
No. QubesOS runs regular Fedora or Debian inside qubes, with no additional hardening added, and in fact some removed. This includes dom0, which runs Fedora.
There has generally been a view that security hardening should be done between qubes, not within qubes. But this view seem to have changed as of recently, and there have been talks of creating an official SecureBlue template, which would have much hardening, including some hardening features borrowed from GrapheneOS.
Unfortunately, QubesOS doesn’t even implement a reliable way to wipe the content of SSD/NVME disks at all. Not even rerunning the installation program will do that.
To support duress functionality similar to GrapheneOS, QubesOS would have to use an immutable image for dom0 and default VMs which isn’t covered by the disk encryption, and would need to tie the disk encryption to the device TPM through means of a securely deletable token stored on the TPM. As far as I know, QubesOS have only just recently started thinking in terms of moving to having an immutable image for dom0, and mostly to support verified boot better. There is also attempts to support some kind of token for disk encryption stored on the TPM, which is kind of almost working, but unclear to me if it is still credential encryption.
1 Like
Concerning a “duress password”, in principle, you could write an early userspace script that that offers that option when you boot, and another based around kexec that loads a minimal replacement kernel and initramfs for when the system is running. But there would be a few caveats. As @ryrona alluded to, wiping an SSD is a bit fraught. Hardware-based crypto erase is fast and elegant, but requires a lot of trust in the manufacturer, which, given their track record, I would say is misplaced. On the software side, simply wiping the LUKS header makes few guarentees against data remanence, especially over short timescales. Using a TPM would be a solution, as would a wipable smartcard (such as a Nitrokey?). I would recommend the latter anyway since typing out the password that goes into your disk encryption’s KDF is a bit sketchy (in my opinion at least). I’ve developed some custom smartcard/TPM/LUKS scripts for my install. DM me if interested.
curious: I thought there was an option to put the boot directory on a USB Key. I am thinking of the encryption key of the hard drive. There might be the opportunity to wipe gpg on that USB using a Duress Password. then th e only way to get at what is on hard drive is a ‘back up’ of the USB.
Uncertain what you are suggesting, but it is also not possible to wipe USB thumb drives in a reliable way. That is also flash storage. Flash storage is not possible to wipe in a reliable way. Any secure implementation of wiping data will need to involve a token stored on a TPM or Secure Element that can be securely erased. This token should in addition to the passphrase be input to the KDF that derive the actual disk encryption key. This would mean that if that token is securely deleted, it will be impossible to derive the disk encryption key even knowing your passphrase, thus the data is in a cryptographic sense effectively destroyed and impossible to recover for anyone ever.
If you have a TPM you trust, @ryrona’s might be the best route. In addition to the TPM token, you could store a second token on a microsd card, since they are so small and presumably easily physically destroyed (you’d have to develop a technique ahead of time). That way if you have a minute, you can destroy the card and avoid any reliance on the integrity of the TPM. I you don’t have a minute, you still have TPM token erasure as a backup.
I just want to expand a bit on the problem with typed-out LUKS passphrases for flash-based media. Unless you’re absolutely sure that you that there’s no keylogger or hidden camera capturing your passphrase, there exists a risk that can’t be mitigated with frequent passphrase changes. This wasn’t the case with older spinning disks, where you could assume that writes would be in place, and the anti-forensics measures built into LUKS would effectively deal with the occasional sector remap. It’s not unreasonable to assume that your disk’s master key, encrypted under your old passphrase, still floats around on your drive for some time after you’ve changed the passphrase. Using a smartcard to unlock your drive lets you avoid this risk.
There appears to be a PAM for a duress code available.
Secureblue is reproducibly built?
I doubt they are easily destroyed. How would you destroy it in a minute as you say, such that forensics can no longer recover the data? Breaking the card in pieces will accomplish exactly nothing.
I don’t think so, since Fedora isn’t.
Which is more hardened, secureblue, or kicksecure?
I am not very familiar with either, but my impression is that SecureBlue is by far the most hardened out of the two. SecureBlue inherits hardening from Fedora, such as selinux, and hardening from SilverBlue, such as immutable images and some kind of app sandboxing, and then add on the hardened malloc implementation from GrapheneOS and web browser hardenings from GrapheneOS and a few other things. KickSecure doesn’t seem to do any of that, but just enable some kernel hardenings and disable some services and that is it.
It is also a question of trust placed in the developers. Is Whonix more open
and therefore more trustworthy than a distro backed by Fedora, which is
updated by Red Hat?
The developer behind KickSecure/Whonix is certainly more known and trusted in this community.
Why isn’t Fedora more known and trusted? Is this due to Red Hat’s involvment?
Is graphics and hardware driver support truly the reason why Debian is not the
default dom0 OS?
Fedora is literally one of the most well-known Linux distributions, alongside Debian. Why it isn’t as trusted by us as Debian and derivatives are mostly for historical reasons. Debian used to be best for security, as they took security extremely seriously, and was thus the natural base to build a security focused operating system on top of. However, Debian has barely implemented any modern security feature, which is why attention has started to shift towards Fedora instead and SilverBlue/SecureBlue instead. Fedora also doesn’t have reproducible builds, which may make some uneasy.
No.
I am not aware of any specific reason they picked Fedora over Debian.
Debian has reproducible builds?
Yes. For the vast majority of packages.
“Debian has barely implemented any modern security feature” can you explain
this further. It does use reproducible builds.
I don’t know. Tweezers and a lighter, a nail file? Use your imagination.
sorry my english…what does this mean?