3 ms·

The "perfection" I want is "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as r

by rdl 11y ago

The "perfection" I want is "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps". I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. These probably don't matter much for individuals but do matter for enterprise. If this existed, even if it were just keys to approve/sign updates and still required google services for a lot of the functionality, would be awesome.

magicalist 11y ago
> I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. Isn't the verified boot portion of the firmware not reflashable without hardware modifications[1]? Even if the dev switch has been flipped before, a verified boot is a verified boot and the machine should be in a good state. I haven't looked at that since the early ChromeOS machines, so has something changed about that? [1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot https://www.chromium.org/chromium-os/chromiumos-design-docs/...
- rdl 11y ago
  Yeah -- it's supposed to be physically Read Only. There are some corner cases requiring physical access (you could physically replace the RO firmware, or fake the switch). I don't think it does full remote attestation validation of the local OS before talking to cloud services, although it does some other stuff. I should look into that more. But really, what I want is the ability to put my own enterprise key in there, in a write-once area, and do exactly what Google does now.
bobajeff 11y ago
> "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps" That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's. I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.
- groby_b 11y ago
  You're seeing the contradiction between having a verifiably "good" device and the ability to change the update/sync server at will, right?
  - rdl 11y ago
    Write-once of an enterprise key. If you buy 10k units, you should be able to put your own key in there. Or, have some kind of "we just check keys and add a layer of indirection as a service" for boot and boot signing keys. A batch of devices (identified by range of manufacture-time keys) is registered to a specific enterprise, and then that enterprise's keys are allowed to boot. That involves some kind of network service at boot time, or some kind of signed second-stage loader delivered to the devices telling them they're authorized to boot only from third-stage signed by that registered key.
  - bobajeff 11y ago
    I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".
    - rdl 11y ago
      It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage). It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.
      - bobajeff 11y ago
        Why wouldn't you be able to treat them as identical? How would being able to change the sync/verification server make Chromebooks vulnerable like those conventional machines?

by rdl 11y ago

magicalist 11y ago

> I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state. Isn't the verified boot portion of the firmware not reflashable without hardware modifications[1]? Even if the dev switch has been flipped before, a verified boot is a verified boot and the machine should be in a good state. I haven't looked at that since the early ChromeOS machines, so has something changed about that? [1] https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot https://www.chromium.org/chromium-os/chromiumos-design-docs/...

rdl 11y ago
Yeah -- it's supposed to be physically Read Only. There are some corner cases requiring physical access (you could physically replace the RO firmware, or fake the switch). I don't think it does full remote attestation validation of the local OS before talking to cloud services, although it does some other stuff. I should look into that more. But really, what I want is the ability to put my own enterprise key in there, in a write-once area, and do exactly what Google does now.

bobajeff 11y ago

> "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps" That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's. I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.

groby_b 11y ago
You're seeing the contradiction between having a verifiably "good" device and the ability to change the update/sync server at will, right?
- rdl 11y ago
  Write-once of an enterprise key. If you buy 10k units, you should be able to put your own key in there. Or, have some kind of "we just check keys and add a layer of indirection as a service" for boot and boot signing keys. A batch of devices (identified by range of manufacture-time keys) is registered to a specific enterprise, and then that enterprise's keys are allowed to boot. That involves some kind of network service at boot time, or some kind of signed second-stage loader delivered to the devices telling them they're authorized to boot only from third-stage signed by that registered key.
- bobajeff 11y ago
  I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".
  - rdl 11y ago
    It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage). It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.
    - bobajeff 11y ago
      Why wouldn't you be able to treat them as identical? How would being able to change the sync/verification server make Chromebooks vulnerable like those conventional machines?