Impose Access Restriction to the Recovery Shell

[biergaizi]

Currently, HEADS will prompt a recovery shell under any fault conditions, it may not be a concern in a perspective of security. However, unlike other bootloaders, such as GRUB which only has read-only access to the disk with minimum risks of data destruction, HEADS is a fully-functional Linux-based operating system with full R/W access to the hard drive and hardware.

It enables extremely easy vandalism for script kiddies with physical access to the machine via the recovery shell, i.e. a keyboard-only denial-of-service attack. With keyboard-only access to an unguarded machine (such as a public machine in a lab), the script kiddie is able to...

• Removing any data from the hard drive.
• Changing the system time and invalidate TOTP.
• Resetting the TPM.
• Destroying the boot firmware.

within a minute or two.

It may be a serious issue depending on one's threat model. For example, public computers are especially vulnerable. Major bootloaders, such an GRUB, allows programming a hashes password to the configuration script for access restrictions to the boot entry and the shell prompt. With access control, vandalism is only possible by physically disassembling the machine, which can be much harder.

In order to implement access control, two types of changes are needed.

1. First, the recovery shell is provided unconditionally under a fault condition, for example, in initrd/init.

   # We should never reach here, but just in case...
   recovery 'Boot script failure?  Entering recovery shell'
   # belts and suspenders, just in case...
   tpm extend -ix 4 -ic recovery
   exec /bin/ash
   

   In an unexpected fault conditions, exec /bin/ash should be replaced with exit to trigger a kernel panic immediately.

2. For expected fault conditions and system maintenance, such as a TOTP mismatch, initrd/bin/generic-init should include an authentication scheme, for example a hashed password checkpoint, or a digital signature verification routine, to ensure the recovery shell access is obtained only under proper authentication.

[biergaizi]

3. Is it possible to bypass the checkpoints by pressing Control-C? If so, it can be pretty problematic.

[flammit]

Adding #217 to this thread and closing it as a dup.

[persmule]

Unexpected fault conditions should be handled with die() rather than recovery().
@citypw Could you help us to review resolutions of this issue?

[itay-grudev]

This will be relatively easy to bypass. You boot from USB and re-flash the BIOS with a factory default. Essentially this only protects from an inexperienced evil maid tampering with the recovery shell (Not so inexperienced if they can know how to use the recovery shell).

To make this better you will need to password protect boot options as well. And then you threat is: an evil maid with an SPI programmer.

In the end I am not sure this is going to be very beneficial. If you forget your password you will have to bother with the steps above to defeat this benign "security" measure.

Of course resetting the boot loader is tamper evident. But so is modifying anything - the boot loader or the /boot partition. So the overall security improvement of this is essentially minimal. Wouldn't you agree?

[biergaizi]

And then you threat is: an evil maid with an SPI programmer.

Not really.

An individual under the threat of an evil maid needs to adopt a radically different set of security protections. If someone can physically remove the hard drive, why bothering to dd if=/dev/zero of=/dev/sda in the recovery shell? Or the attacker can replace the motherboard with a backdoored one as well. Or simply steal the computer.

Instead, the threat model for this is clearly stated in the beginning. To protect public computers, like those in a lab, an office or a hackerspace, from easy vandalism.

vandalism from script kiddies with physical access to the machine via the recovery shell, i.e. a keyboard-only denial-of-service attack. With keyboard-only access to an unguarded machine (such as a public machine in a lab), i.e. a keyboard-only denial-of-service attack.

It's a fairly realistic scenario. Have you seen what are 14-year-old script kiddies capable of doing on a public computer 😄 ? It's also useful for someone who wish to set up a few public computers in a hackerspace without worrying about having to reinstall the OS everyday.

Basically it's what a BIOS password does. It's useless to defend the system against any attacker, but especially useful for stopping someone messing up with the boot process with a keyboard.

Do you see my point here?

To make this better you will need to password protect boot options as well.

Good point. Something similar to GRUB's boot lock should be implemented as well.

If you forget your password you will have to bother with the steps above to defeat this benign "security" measure.

If you are sure that you are not going to be benefited from it, just use "password123", or disable it.

[tlaurion]

@biergaizi @citypw @persemule @itay-grudev?

Following you discussion:

• USB Security device could be used as per Impose Access Restriction to the Recovery Shell #361 on recovery shell and usb code path if defined in board config.

Would that deal with all your concerns? Problem here would be to have a way to put back private keys inside of new USB security dongle if lost, which would require in recovery keypair generation, saved on encrypted external storage and then those keys to be copied in USB security dongle so that it is possible to copy them back on USB security dongle when needed, while permitting users to boot unsigned boot configurations that are already on disk while unsigned per user. I have not better idea.

[tlaurion]

Still interesting

[itay-grudev]

@tlaurion I believe your suggestion would stop the specified by @biergaizi script kiddie attack in the ever so elegant way using Librem keys, so I agree - this solution does make sense.

[tlaurion]

Authentication should also be asked prior of flashing ROM. (prior of all flashrom calls)

Not sure where/how to put this correctly in line with #771, which needs to reflash rom with public key generated, which would require flash authentication. (With a private key for which there is no public key but in local keychain. Check against local keychain?)

@flammit : ideas?

[tlaurion]

Authentication should also be asked prior of flashing ROM. (prior of all flashrom calls)

Not sure where/how to put this correctly in line with #771, which needs to reflash rom with public key generated, which would require flash authentication. (With a private key for which there is no public key but in local keychain. Check against local keychain?)

Actually, as discussed #326 (comment) there might not be any need to authenticate flashing operations, which could be the mitigation plan in case of having lost USB Security dongle being replaced by a new one, or having an expired public key needing to be extended.

Factory resetting newly received USB Security dongle replacement/Flashing a new public key would resolve the issue there, while what is really needed is a way to authenticate at the recovery shell. As in referred link above, the two thought authentication methods would be:

• TPM Disk Unlock Key passphrase, validating that all firmware measurements are valid and sealed with LUKS now measured full headers and TPM NVRAM region passphrase to unseal the secret.
• GPG User PIN to test signing capability of the user against public key already fused inside of ROM, confirming both PIN and public key fused are valid.

Thoughts?

[tlaurion]

Integrated in #1515