Linked by Thom Holwerda on Mon 4th Feb 2013 22:10 UTC
Thread beginning with comment 551677
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2011-07-18
The ChromeOS security model relies on having hardware write-protection over the part of the firmware which is used in early boot. If the user disables the write-protection, then it's very possibly to insert your own keys into the firmware image. There is even a script that ships on all ChromeOS systems which will do this for you at /usr/share/vboot/bin/make_dev_firmware.sh
The ChromeOS team's biggest problem here is not documenting this process better for each device. So far though, very few people have even asked how to do it.
The ease of disabling the write protection is also highly variable between different ChromeOS devices. For example on the Samsung ARM Chromebook, it is just a screw which needs to be removed. There's a tension between ease of removing the write-protect and security against "walk-by" attacks.
But the system wasn't intentionally designed to lock out the owner at all, which is what the blog post implies, and that is very unfortunate.