On Oct 29, 2023, at 16:22, Samuel Sieb <samuel(a)sieb.net> wrote:
On 10/29/23 12:47, Roberto Ragusa wrote:
>> On 10/29/23 20:16, Jonathan Billings wrote:
>> On Oct 29, 2023, at 11:00, Roberto Ragusa <mail(a)robertoragusa.it> wrote:
>>>
>>> On 10/29/23 04:13, Robert Nichols wrote:
>>>>> On 10/28/23 21:20, Robert Nichols wrote:
>>>>> Yes, as long as the device is currently unlocked
>>>> Oops. I just realized that recovering the master key from the kernel
works only for LUKS1. Your device is using LUKS2, and and accessing the key from userspace
is not possible with LUKS2. Sorry.
>>>
>>> Really? I was not aware of that.
>>> So keeping my systems far away from LUKS2 has been a good idea.
>>
>> This is actually a good thing. Being able to extract a key was a security hole.
> As far as I can see in this thread, it consists in hostility against
> the owner of the machine, which is risking something similar to
> a ransomware event.Data availability is one of the aspects of security, so this
feature
> is indeed a security issue.
That doesn't make any sense. Do you consider it hostility that the owner can't
extract his user password or the root password from the system?
Sometimes information security is gained in exchange for a loss of ease of use. We could
all have no password at all on our systems, let anyone in, but that would have disastrous
results. Likewise, we could keep the password on a scrap of paper under the keyboard,
until someone steals it.
The point I’m making is that the decryption passphrase should not be accessible to any
root level process, be it a user with sudo or a compromised service.
This is why you should create a backup passphrase in a different keyslot and store it
someplace secure, just in case.
--
Jonathan Billings