In fact, I would say for some users, Chrome OS is near perfection. Take my uncle for instance, who for years was getting himself infected with malware requiring regular visits from me or geek squad to wipe his system. When he was ready for his most recent upgrade, I tried him on Mint, but he didn't like the interface. Then I suggested a Chromebook. He LOVES IT. He says it's the best machine he's ever owned. One year later, and not a single issue with malware.
I don't worry about him getting infected. If instead of a Chromebook, he had gotten some Android tablet with an OS stuck at 4.x, he's likely be infected by now.
Android and Chrome OS serve different use cases. Even if Android manages to fix their upgrade issue, I doubt it will ever be as secure as Chrome OS. From the blog, "guaranteed auto-updates for five years", sounds like a few people at Google get this. Fingers crossed.
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.
> "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.
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.
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".
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.
> Why wouldn't you be able to treat them as identical?
If a given machine can have arbitrary software installed on it, then that machine can behave differently than other machines in the fleet.
If all machines in your fleet can only install and/or run software signed with the company key, then the company can ensure that the software load for all machines remains the same and -thus- all machines behave identically.
> How would being able to change the sync/verification server make Chromebooks vulnerable...
If the software repo and/or verification server can be changed by a third party, and the trusted keys installed in the machine can be changed, then it's trivial to pwn such a machine. If only the servers can be changed, then it requires loss of control of one's signing keys to pwn such a machine. [0]
[0] Or -obviously- a sufficiently bad privilege escalation bug can pwn such a machine.
Where do they make money on that? The margins on the devices are so slim and go to the OEMs, which Google mostly isn't. I don't think they charge any money for OEMs licensing the OS, and if they do it's likely a pittance. The only way Chromebooks make money for Google is as a gateway to Google services, and allowing people to fork ChromeOS like that puts that revenue source in jeopardy.
> 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?
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.
he's likely be infected by now - What kind of infections would these be viruses/malware? Other day there was security expert who mentioned how Android security was bad, but did not mention any specific cases. My dad uses a 4.x device. Many other as well( India where low end has 4.x devices). But i don't see these user complaining about viruses or malware. Considering that they would usually complain about virus affecting their windows os. Is there anyway to know if the devices are infected?
Even Android have a much better security model than your traditional desktop OS. Except if the malware includes a root exploit (in this case, all bets are off), the traditional "malware" in Android is limited to basically what the user allows it. However malware including root exploits should be rare, at least if the user only install applications using Google Play. Using applications from other sources, specially to get "free versions" of paid applications can be really bad.
Unless the user are a completely moron, without enabling access for Accessibility, a malicious app can't, for example, read everything on the user screen, or capture the information the user types (the user would need to explicit allow it by turning on keyboard servicesin this case). This means that a malware can't sniff login information, or read the user e-mail. However they can still get valuable information (if the user did not read the permissions that Android asks before performing installation), like user contacts.
In fact, I would say for some users, Chrome OS is near perfection. Take my uncle for instance, who for years was getting himself infected with malware requiring regular visits from me or geek squad to wipe his system. When he was ready for his most recent upgrade, I tried him on Mint, but he didn't like the interface. Then I suggested a Chromebook. He LOVES IT. He says it's the best machine he's ever owned. One year later, and not a single issue with malware.
I don't worry about him getting infected. If instead of a Chromebook, he had gotten some Android tablet with an OS stuck at 4.x, he's likely be infected by now.
Android and Chrome OS serve different use cases. Even if Android manages to fix their upgrade issue, I doubt it will ever be as secure as Chrome OS. From the blog, "guaranteed auto-updates for five years", sounds like a few people at Google get this. Fingers crossed.