#1

Maybe a naive and totally obvious question, but anyway…

Is it still possible to use full-disk encryption with CoreOS?

Especially when reading about ignition (see also this thread) I can hardly imagine that I can enter/provide a password there somewhere – or possibly even deliver it remotely.

That said, I am open to alternatives. So another question would be:
How can one ensure proper confidentiality with at-rest encryption in CoreOS otherwise?

I always just consider FDE the easiest thing, which also means you can hardly screw up by e.g. forget to include one thing in the encryption.

#2

Is your system capable of running coreboot rather than stock bootcode, or do
you have some other bootcode in use where FDE is possible?

#3

I have no specific system in mind and my question was rather generic. That said, I also would find it strange to do FDE in the bootcode, all systems I knew only did it via luks in Linux itself. Also, this way I know that it uses trusted, FLOSS components and some potentially weird bootcode encryption implementation. (looking at you “self-encrypting disks”)

#4

FDE was discussed in https://github.com/coreos/fedora-coreos-tracker/issues/18

#5

OH, you’re referring to encrypted partitions, not full disk encryption. I was
suggesting using the entire disk as a LUKS block device. My system, for
example, uses Libreboot with a GRUB payload to decrypt the disk and grab my
kernel from my LVM root volume.

#6

Ah, yes, I missed these pesky technical details. So yes, strictly speaking I just want a partition encryption. That said, I just want a similar encryption as anaconda (or others) do on desktop systems or so.
So in other words, yes, some data may not be encrypted, but at least sensible data (e.g. user data from containers or so) shall be encrypted. (In laptop contexts or so, that is often still referred as to “FDE”, even though some root partition or so may not be encrypted.)
Or any good alternative solution that can be done via ignition or so?

#7

So https://github.com/coreos/fedora-coreos-tracker/issues/18 just seems to be about the partition layout mostly. I see no finished advice/guide on how to do it. It was also linked to this issue, which is basically want I want to achieve, but there is no solution there yet, as far as I see.

Where the password/key comes from is another discussion. Basically I would already be satisfied with the usual graphical/text input, so when you attach a keyboard you can enter it. (Again, just as you know it from your desktop/laptop.)

Clever alternatives like SSH input or even TPM are also nice to suggest, but they usually require much (low-level-)fiddling and may easily fail/break…
As such, I’d really want a stable/proven, but secure way, so IMHO the “password input” is the best one currently available.

#8

I don’t think there’s much desire for encrypted /boot. Nothing sensitive should be in there anyway and it makes implementation much easier if its not. Encrypted root relies on being able to blow away the rootfs and recreate it (which means fetching it over network or some other source of truth). Other encrypted partitions aren’t as much of an issue since tools in the real root can decrypt them*. We definitely want the ability to fetch decryption passphrases from cloud services. There’s really several parts:
*Ignition should still learn how to create them, but you can work around this with systemd units with ConditionFirstBoot.

  1. Ignition needs to know how to create LUKS devices
  2. The initramfs needs to know how to repopulate the rootfs from network (or some other source of truth) if it was blown away to make an encrypted partitions
  3. There needs to be some tool in the initramfs that can fetch passphrases to decrypt disks (whether this be from cloud services, the console, etc). This should also be included in the rootfs for non-root encrypted partitions.
  4. The initramfs needs to know what it needs to do to find and mount the root partition (see https://github.com/coreos/fedora-coreos-tracker/issues/94). We have a static initramfs, so we need some way of passing in configuration saying "this is part of a special block device (i.e. encrypted, raid, etc) that contains the root partition (or contains nested special devices that contain the root partition) and it needs to be started/decrypted/etc before we try to switch root. For CL we used partition type guids. See https://coreos.com/os/docs/latest/root-filesystem-placement.html
1 Like
#9

I don’t think there’s much desire for encrypted /boot. Nothing sensitive
should be in there anyway and it makes implementation much easier if its
not.

Encrypted /boot would prevent the proverbial “average bear” from being able to
inject code into your system and from learning the layout, among other
benefits.

We definitely want the ability to fetch decryption passphrases from cloud
services.

How would you suggest doing this in a secure manner? That sounds pretty scary
in my opinion…

1 Like
#10

Isn’t this basically Secure Boot?

#11

[quote=“JohnMH, post:9, topic:994”]
Encrypted /boot would prevent the proverbial “average bear” from being able
to
inject code into your system
[/quote]

Isn’t this basically Secure Boot?

Not exactly. Secure Boot offers something similar, but it relies on a trust
model which includes vendor keys.

On my system, for example, the entire disk is a luks encrypted block device +
LVM.