Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

mathstodon.xyz

Post reply on HN
Print view View original

81–90 of 247 posts

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#81

Post by saidnooneever »

IngoBlechschmid wrote: post #37
steve918 wrote: post #23

Earlier quoted context omitted.

I wonder if you think other OSes are any different? TempleOS is the only thing that comes to mind that doesn't fit your description and it's not practically useful. Any sufficiently large codebase is a mix of ideas and concepts implemented by different people with different priorities over a large timespan and if you can fit the entire thing in your head it's not very interesting or complex.

Qubes OS, the Linux distribution aspiring to offer a reasonably secure operating system, pioneering a "every app runs in a virtual machine" approach in the Linux laptop/desktop space, tracks this at the following issue: https://github.com/QubesOS/qubes-issues/issues/2890

QubesOS is Xen based. Not Linux.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#82

Post by moritzwarhier »

bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

The whole premise of a "giant secure open source C codebase" seems questionable

Because code review is sometimes not much different from an idealized version of the halting problem, where you would have access to a formalized version of a specification.

In other words, there is no strict definition of what is a security issue.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#83

Post by dijit »

j16sdiz wrote: post #79
dijit wrote: post #50

Earlier quoted context omitted.

if by "great" you really mean "fine". It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform. Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.

> Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) Did you read the documentation? https://support.apple.com/guide/mac-help/protect-data-on-you... "iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud." https://developer.apple.com/documentation/device…

Can.

If you click "Allow my iCloud account to unlock my disk", your recovery key is escrowed to Apple, tied to your Apple Account.

If you don't select that option it never does.

I should have said "without your explicit permission", but I assumed we were all adults and understood that.

The main point is that it's using your account password to unlock, the recovery key is for if you forget your account password.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#84

Post by bri3d »

IngoBlechschmid wrote: post #34
naturalmovement wrote: post #24

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).

BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#85

Post by lazide »

bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

In open source, someone (many, many) someone’s can at least check.

Closed source…..

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#86

Post by noinsight »

IngoBlechschmid wrote: post #34
naturalmovement wrote: post #24

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#87

Post by john_strinlai »

dijit wrote: post #74
john_strinlai wrote: post #55

Earlier quoted context omitted.

> if by "great" you really mean "fine". no, i mean great. managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all). on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it. for personal use, i do…

Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems. Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid yo…

maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#88

Post by bri3d »

dijit wrote: post #74
john_strinlai wrote: post #55

Earlier quoted context omitted.

> if by "great" you really mean "fine". no, i mean great. managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all). on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it. for personal use, i do…

Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems. Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid yo…

Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.

I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#90

Post by dijit »

john_strinlai wrote: post #87
dijit wrote: post #74

Earlier quoted context omitted.

Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems. Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid yo…

maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)

If you use your key every day you tend not to forget it.

If I as an admin give you your key: it is “leaked” effectively.

Post reply on HN