Keeping the key in the same room as the padlock only protects against casual drive theft and secure disposal.
Personally I'm more worried about someone stealing the entire server or a local threat actor.
Sure, keep TPM to help with boot integrity, maybe even a factor for unlock, but things like Clevis+Tang (or Bitlock Network Unlock for our windows brethren) is essential in my opinion.
TPM locking is for ensuring the disk isn't removed from your machine. It's technically possible that someone could tap the hardware while the disk is still in your machine, but otherwise they're stuck contending with whatever other security setup you have on your machine.
The TPM locked disk encryption is more like embedding your safe in concrete with deep foundations. It doesn't affect the thickness or quality of your safe.
The beta installer was completely unsuccessful in setting the TPM-backed disk encryption on both a ThinkPad X1 Carbon (Intel 258V) and a ThinkPad P14s (AMD 300-something). Hopefully they ironed that part out in the release, but it seems still early for this feature (at least for my comfort level).
The constructed policy is quite strict and expects certain UEFI things to be set up correctly. For example both this https://github.com/canonical/secboot/blob/7434bac27844362ff8... and https://github.com/canonical/secboot/blob/7434bac27844362ff8... are enabled in the policy. The policy choices and various early checks, even as trivial as confirming that the TCG log content is correct after booting into installation system, are enough to rule out a lot of potentially problematic EFI deployments. Effectively making it more strict helps avoid a lot of funny issues where the firmware is clearly buggy and things would fall apart sooner or later.
Strict is probably good. My company started to enable bitlocker this year on win11, and a non trivial amount of initial encryptions seem to be failing, destroying the user data and requiring a full reformat.
In what way is TPM protecting your data if someone steals the entire server? TPM only ensures that the boot environment has not been modified. Whatever key is being used to automatically decrypt the disk would be in the clear.
Unless I'm misunderstanding your situation, I think you should look up the "Evil Maid Attack" to better understand how to mitigate risk for your threat model.
assuming there are no bugs in linux and you enable full memory encryption in BIOS, it protects you in the same way the FBI cant get into a locked iphone they physically posess
but linux is not as secure as an iphone, and linux users typically dont know how to set this up, so in practice you are right, it doesnt protect you
My threat model is a junkie breaks in to my house and flips my server on facebook marketplace. Then the buyer curiously pokes through my hard drives. Of course if protecting against government agencies is the threat model then TPM alone isn't enough.
For me, a zero friction way to have decent security is worlds better than the normal state where homeservers are not encrypted at all.
I just don't understand where the protection comes from if you have automatic password entry. If the thief boots up the server it is just as convenient for them as it is for you.
Your threat model is the same as my use of a laptop: regular LUKS with a password is enough on its own. Add TPM if you want to know that you're entering your password in a secure boot environment (ie. protect against a fake LUKS screen that steals your password).
Because you'll boot up in to a password prompt. So you'd need a password bypass exploit to get in. If you attempt to change the boot device or kernel the TPM won't release the key.
Yes, but not by automating the password process. You could probably do some sort of remote authentication with a custom iniramfs that will "phone home" for a key but that initramfs, even if signed and protected from tampering, is still exposing the authentication end point.
The attacker would just need to spoof the request to gain the key.
Great question! We rebuild if there's a security update or otherwise every few weeks. We're working on a better method, but right now a few templates can be kept warm so users aren't forced to reboot.
We're working on a similar solution at UnixShells.com [1]. We built a VMM that forks, and boots, in < 20ms and is live, serving customers! We have a lot of great tools available, via MIT, on our github repo [2] as well!
? You say 'yes' but you seem to be answering a different question. Docker desktop only makes me choose a max ram - it dynamically scales RAM usage. I don't need fully automatic like that, but the ability to vertically scale RAM for an existing instance is really important, particularly given the cost of RAM these days.
Use latch to ssh, mosh or web into your machine. latch multiplexes terminal windows (like screen or tmux).
We built this for use on UnixShells [1].
All remote connections are verified against the authorized_keys and are, of course, end to end encrypted.
This is MIT licensed. There is also a relay that lets you connect to your latch sessions that are behind NAT - this has a small cost to it for infrastructure. However, you can use tailscale/ngrok or your own external IP for free.
I don't know if I agree or not with his views, but the fact that he's moving from complaining about something, to doing something about his beliefs, has convinced me to move from a negative to a significantly positive view of him, as a person; to reiterate, regardless of whether I agree with said views.
The will to fight for what one believes in - I think we can all agree that is an admirable human trait that would result, for those who do follow his views, in him being labeled as a hero and defender of people's rights.
> He once tweeted that seven of the city’s supervisors — all progressives — should “die slow, motherfuckers” in a late-night polemic. The tweet, which Tan said was a joke, prompted hateful mail and police reports.
Yeah, my benefit of the doubt (which was already zero for a rich person in politics) is negative.
This is going to be very useful for servers hosted in third party DCs.
reply