Hardening: allow protecting against malicious console access

[travier]

Describe the enhancement

In some cases, we want to be able to setup systems where access to an interactive console does not constitute a security issue. This also requires that the boot process is locked down via a GRUB password for example to prevent kargs changes and that the disks can not be accessed directly.

To make that possible, any daemon or network failures (post first boot) should never result in an emergency shell being available by default, either in the initrd or the final system. Failing on first boot before the configuration is fetched via Ignition is still acceptable as the system should not have access to any secret at that point. Any later failure could leak secrets from the config or the system. We could also exclude the first boot entirely from the threat model.

This would also be of interest once we get mesured / trusted boot supported on FCOS.

This came out from discussions regarding #796

[bgilbert]

The issue title seemed too specific to me, so I've generalized it some.

Before the config is fetched, the system does have access to secrets: a malicious user could fetch the config. They could also just compromise the system.

We should be explicit about the threat model here. If we don't think we need to harden the first boot, let's spell out the justification for that; is the assumption that a trusted user is sitting at the console during install? That'll be true for some use cases but not all.

There are several elements of a hardening effort:

• Controlling access to change the bootloader config, including kernel selection and kargs, both in the live ISO (if using that) and in the installed system. Presumably live PXE setups can handle their own bootloader hardening.
• Controlling access to the initramfs e-shell
• Controlling access to the real root e-shell

To make that possible, any daemon or network failures (post first boot) should never result in an emergency shell being available by default, either in the initrd or the final system.

I think we'd want to password-protect the emergency shell rather than disabling it.

[travier]

Good points! Thanks for the update.

I think we'd want to password-protect the emergency shell rather than disabling it.

Oh, indeed, that makes much more sense and would instantaneously resolve most of the concerns for real root e-shell.

[bgilbert]

Hardening the bootloader config is #134.

[travier]

To make that possible, any daemon or network failures (post first boot) should never result in an emergency shell being available by default, either in the initrd or the final system.

The config https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d/05core/usr/lib/systemd/system/emergency.service.d/coreos-sulogin-force.conf added in coreos/fedora-coreos-config#311 makes hitting a filesystem check error on boot drop a root shell in all cases, which is contrary to the goal of this issue. According to https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html#emergency.target:

emergency.target:
...
it is also used when a file system check on a required file system fails and boot-up cannot continue.
...

So this is not great because even systems properly configured with a root password can get compromised if a filesystem check fails. Making a filesystem check fail is likely doable for an attacker even if the system has LUKS setup for the root partition with a TPM binding as /boot is not protected.

Not sure how this could be fixed.

[travier]

So this is not great because even systems properly configured with a root password can get compromised if a filesystem check fails. Making a filesystem check fail is likely doable for an attacker even if the system has LUKS setup for the root partition with a TPM binding as /boot is not protected.

This specific issue is fixed by coreos/fedora-coreos-config#2841.