4 ms·

> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll

by bitwize 9mo ago

> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys. Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.

NekkoDroid 9mo ago
I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...
- bri3d 9mo ago
  What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
  - NekkoDroid 9mo ago
    It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
    - bri3d 9mo ago
      What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
      - fc417fc802 9mo ago
        > UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level Baseless FUD. If you have an actual point to make then do so. > All of these "add more nag screens for freedom" No one said anything about a nag screen. You literally just made that up. For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader.
        bri3d 9mo ago
        > Baseless FUD. This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot? PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you. To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine. > No one said anything about a nag screen. The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today. > For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
lacunary 9mo ago
I have always enjoyed the experience of installing my favorite hobbyist teletype operating system. I think the last time I used a preinstalled on a personal machine was windows 3.1 on a 486.

by bitwize 9mo ago

NekkoDroid 9mo ago

I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...

bri3d 9mo ago
What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
- NekkoDroid 9mo ago
  It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
  - bri3d 9mo ago
    What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
    - fc417fc802 9mo ago
      > UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level Baseless FUD. If you have an actual point to make then do so. > All of these "add more nag screens for freedom" No one said anything about a nag screen. You literally just made that up. For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader.
      - bri3d 9mo ago
        > Baseless FUD. This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot? PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you. To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine. > No one said anything about a nag screen. The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today. > For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.

lacunary 9mo ago

I have always enjoyed the experience of installing my favorite hobbyist teletype operating system. I think the last time I used a preinstalled on a personal machine was windows 3.1 on a 486.