Re: [oS-EN] Question on full disk encription
On 3/28/23 08:01, cagsm wrote:
On Tue, Mar 28, 2023 at 12:42 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
new laptop here, and I decided to install Leap 15.4 with full disk encryption, no LVM (a feature I wanted to have for years, so I'm happy). It asks for the password twice (contrary to my customs, I'm using plymouth). It asks once before grub loads. Well, ok, there is no separate /boot, so it has to read "/" which is encrypted. Nice. But after selecting the boot entry in grub, it asks again. Once, despite being 3 partitions ("/", "/boot" and swap). Ok.
doesnt the official opensuse pages state about the situation about double entry of passphrases. i have double passphrase questionaire as well with 15.4 fresh install via the propsed partition setup on a notebook. btrfs or something and the snapshot filesystem stuff and all. not expert though
The page says: <quote> Warning: Do this only if you have an encrypted root partition **that includes /boot** (no separate /boot partition)! The key added to the initrd can be used to decrypt your root partition, therefore having the initrd on an unencrypted /boot partition would defeat encrypting your root partition. </quote> How do you handle the case of a separate /boot partition? -- David C. Rankin, J.D.,P.E.
On Wed, Mar 29, 2023 at 9:39 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do you handle the case of a separate /boot partition?
What exactly is your question? If you have an unencrypted boot partition, it is by definition not "full disk encryption" anymore. So what is your goal, what are you wanting to achieve?
On 2023-03-29 09:20, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 9:39 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do you handle the case of a separate /boot partition?
What exactly is your question? If you have an unencrypted boot partition, it is by definition not "full disk encryption" anymore. So what is your goal, what are you wanting to achieve?
I think he means having: /boot / /home All encrypted. (except /boot/efi partition) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Mar 29, 2023 at 2:05 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2023-03-29 09:20, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 9:39 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do you handle the case of a separate /boot partition?
What exactly is your question? If you have an unencrypted boot partition, it is by definition not "full disk encryption" anymore. So what is your goal, what are you wanting to achieve?
I think he means having:
/boot / /home
All encrypted.
(except /boot/efi partition)
/boot != /boot/efi. System with unencrypted /boot (or generally - whatever filesystem is used to load kernel/initrd from) is easily compromised by replacing kernel and/or initrd if physical access to the system can be obtained. To protect (against such offline compromise) you need TPM and measured boot, but it is not supported by Leap 15.4.
On 2023-03-29 13:38, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 2:05 PM Carlos E. R. <> wrote:
On 2023-03-29 09:20, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 9:39 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do you handle the case of a separate /boot partition?
What exactly is your question? If you have an unencrypted boot partition, it is by definition not "full disk encryption" anymore. So what is your goal, what are you wanting to achieve?
I think he means having:
/boot / /home
All encrypted.
(except /boot/efi partition)
/boot != /boot/efi.
I know, that's why I wrote them separate.
System with unencrypted /boot (or generally - whatever filesystem is used to load kernel/initrd from) is easily compromised by replacing kernel and/or initrd if physical access to the system can be obtained. To protect (against such offline compromise) you need TPM and measured boot, but it is not supported by Leap 15.4.
Yes, but his question, I assume, is if it is doable to have a separate /boot partition, encrypted (while ESP is not encrypted), instead of having /boot as a directory of "/", and still boot with typing the password just once. I don't know why he wants a separate /boot. Maybe raid or LVM setups. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Mar 29, 2023 at 2:46 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Yes, but his question, I assume, is if it is doable to have a separate /boot partition, encrypted (while ESP is not encrypted), instead of having /boot as a directory of "/", and still boot with typing the password just once.
Of course. How does it matter where /boot is located?
On 2023-03-29 13:48, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 2:46 PM Carlos E. R. <> wrote:
Yes, but his question, I assume, is if it is doable to have a separate /boot partition, encrypted (while ESP is not encrypted), instead of having /boot as a directory of "/", and still boot with typing the password just once.
Of course. How does it matter where /boot is located?
:-) Well, some features break when using a separate /boot partitions. For instance, rollback :-p (yes, yes, I know why it doesn't work with a separate boot. Just a silly example) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 3/29/23 7:38 AM, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 2:05 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2023-03-29 09:20, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 9:39 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
How do you handle the case of a separate /boot partition?
What exactly is your question? If you have an unencrypted boot partition, it is by definition not "full disk encryption" anymore. So what is your goal, what are you wanting to achieve?
I think he means having:
/boot / /home
All encrypted.
(except /boot/efi partition)
/boot != /boot/efi.
System with unencrypted /boot (or generally - whatever filesystem is used to load kernel/initrd from) is easily compromised by replacing kernel and/or initrd if physical access to the system can be obtained. To protect (against such offline compromise) you need TPM and measured boot, but it is not supported by Leap 15.4.
Does TPM prevent tampering with files in /boot/... or at least make it apparent that something there has been tampered with? And what is meant by "measured boot"? Thanks.
On Wed, Mar 29, 2023 at 4:38 PM gebser@mousecar.com <gebser@mousecar.com> wrote:
System with unencrypted /boot (or generally - whatever filesystem is used to load kernel/initrd from) is easily compromised by replacing kernel and/or initrd if physical access to the system can be obtained. To protect (against such offline compromise) you need TPM and measured boot, but it is not supported by Leap 15.4.
Does TPM prevent tampering with files in /boot/... or at least make it apparent that something there has been tampered with?
No, TPM alone does not.
And what is meant by "measured boot"?
Components involved during boot are checked and if they were found to be modified it is possible to refuse to boot, to refuse decryption etc. TPM is used as a trusted blackbox to store results/private keys that cannot be tampered with. Did you try to google it?
On 3/29/23 9:46 AM, Andrei Borzenkov wrote:
On Wed, Mar 29, 2023 at 4:38 PM gebser@mousecar.com <gebser@mousecar.com> wrote:
System with unencrypted /boot (or generally - whatever filesystem is used to load kernel/initrd from) is easily compromised by replacing kernel and/or initrd if physical access to the system can be obtained. To protect (against such offline compromise) you need TPM and measured boot, but it is not supported by Leap 15.4.
Does TPM prevent tampering with files in /boot/... or at least make it apparent that something there has been tampered with?
No, TPM alone does not.
That's disappointing.
And what is meant by "measured boot"?
Components involved during boot are checked and if they were found to be modified it is possible to refuse to boot, to refuse decryption etc. TPM is used as a trusted blackbox to store results/private keys that cannot be tampered with.
Do the components which are checked include the BIOS ("BIOS" broadly meaning the hardware responsible for booting before any "disk" is read)?
Did you try to google it?
Quite a bit actually. What I found was, unfortunately, either overly simplistic or technically over my head.
On 01.04.2023 07:15, gebser@mousecar.com wrote:
Components involved during boot are checked and if they were found to be modified it is possible to refuse to boot, to refuse decryption etc. TPM is used as a trusted blackbox to store results/private keys that cannot be tampered with.
Do the components which are checked include the BIOS ("BIOS" broadly meaning the hardware responsible for booting before any "disk" is read)?
They should be according to specification, but at the end you are at the mercy of your vendor to implement it correctly.
Did you try to google it?
Quite a bit actually. What I found was, unfortunately, either overly simplistic or technically over my head.
Well, the idea is simple indeed and the devil is as usual in implementation details.
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
gebser＠mousecar.com