Just FYI: Chrome OS devices are not subject to roll back attacks because the verified boot does not allow that. Google has extensive documentation on this, and you can review the implementation by viewing the source code. Rollback attacks were an attack vector they specifically designed to prevent. In fact as a chrome OS user this is as much an disadvantage as it an advantage: updates are forced- you can not go back and bug regressions which don't effect security but that are annoying can occur and there isn't anything you can do about that. Also, it isn't just verified boot an attacker would have to overcome. The DM verity means any OS and onboard application code must checksum correctly or it will never run, this is true at all times. Realize as well that all of this code is always running off read only file systems. Note that the builtin data partition (not executable code, in fact data filesystem is mounted no exec) encryption is defeatable in the minimal sense that Chrome OS does allow users to choose to not have to login when waking from sleep, so user stupidity allows a small opening here. Heh- happened to me. Lost my chromebook and could not remember if I had left it "locked" (long story!), but I knew it was asleep. Finderay have had access to my login session, albeit og little use since I changed my password and I believe this deactivated access to current email login, eg. Also enterprise administrators may have the option of overriding user choice here, saving users from their stupidity. Another interesting point: the onboard ssh client is implemented partially in javavscript (the terminal portion). Before you whince, know that Google argues this is more secure than normal ssh Unix clients because in addition to all the usual ssh protections, it is necessarily running in a Chrome sandbox! They are probably right about that? I think so. Finally, I wrote up some stuff on their wiki: you can run in dev mode but still have fully verified boot and auto update. This gives the machine a larger local attack surface (not remote though), but opens access to some Unix user land such as the onboard openssl which you could use for additional encryption. Not too that chrome is devices share well and do while totally protecting users from each other. Not a security expert myself. But I have been administering Unix systems fulltime for over 15 years. No question in my mind that these things are more secure BY FAR than any other off the shelf solution you can buy as a consumer. That a normal Unix distro could be made to be as secure is IMO not true as well. Google has of course just made Chrome OS the target for their Pawnium challenge this year. Should be interesting! Trever On Feb 6, 2013 8:31 AM, "Tom Ritter" <tom@ritter.vg> wrote:

On 6 February 2013 10:52, micah anderson <micah@riseup.net> wrote:

...

Can you say what you mean here? What is SOP in this context?

ChromeOS's 'Apps' are all extensions or webpages. One can't interact with any other do to the standard Same Origin Policy browsers enforce. It's what stops evilco.com from reading your logged in gmail.com tab in FF/Chrome/IE/any browser today.

...

I would be surprised if you actually 'bricked' these systems, since neither operating system you mention involves a procedure that has the risk of bricking a device. I suspect this is hyperbole?

Well, I have a colleague rebuilding a FDE Ubuntu computer right now because we can't figure out how to repair its partition table and get it to boot without a LiveCD. It's probably possible, but we're pretty technical people and we made the call it would take less time to recreate the machine than 'fix' it. Similarly, I recently paid the gentoo tax while upgrading udev and not having a kernel switch turned on - wouldn't boot, requiring me to LiveCD it, enable the setting, recompile the kernel and replace it.

So bricked in the sense of it's now a brick and might as well be sold for parts - you're right, that's hyperbole. But for a non-technical person, with no access to someone to repair a machine for him/her - I don't know, I think it might as well be bricked. They can't fix it on their own, and it's not going to boot.

...

...

- Verified Boot, automatic FDE, tamper-resistant hardware

All of this reminds me of this post: http://mjg59.dreamwidth.org/22465.html

which concludes:

"Some people don't like Secure Boot because they don't trust Microsoft. If you trust Google more, then a Chromebook is a reasonable choice. But some people don't like Secure Boot because they see it as an attack on user freedom, and those people should be willing to criticise Google's stance. Unlike Microsoft, Chromebooks force the user to choose between security and freedom. Nobody should be forced to make that choice."

I don't disagree with the notion that Chromebooks, Windows 8, iOS, and other examples make you choose between "Insecure and running your own stuff" and "Secure and running their stuff". I completely agree with it. I do disagree with a phrase of your except "Chromebooks force the user to choose between security and freedom" - I would rephrase it "Chromebooks force the user to choose between freedom and Google's stewardship".

My gender-inspecific-nontechnical-family-member is not interesting in running after-market app stores or tethering apps on their phone, so if security was the only concern I would recommend iPhone because it is harder to root. Similarly, if an activist is not going to run third party apps or 'jailbreak' their device (and nobody is going to take the responsibility to do it for them and then be full time tech support) - choosing a more secure, albeit stewarded by Google/Apple, system makes sense. I know some people don't believe this, and I know some people (like RMS) say we should always fight the good fight and never give way...

But if you nailed me down and said "Make a computer recommendation, someone's life may depend on it." Depending on who their adversary is, I would probably not make the Free OS recommendation.

On 6 February 2013 10:52, Rich Kulawiec <rsk@gsp.org> wrote:

...

On Wed, Feb 06, 2013 at 10:24:28AM -0500, Tom Ritter wrote:

...

- ChromeOS's update mechanism is automatic, transparent, and basically foolproof. Having bricked Ubuntu and Gentoo systems, the same is not true of Linux.

Concur on this point, and wish to ask a related question:

Many operating systems and applications and even application extensions (e.g., Firefox extensions) now attempt to discover the presence of updates for themselves either automatically or because a user instructs them to do. Is there any published research on the security consequences of doing so? (What I'm thinking of is an adversary who observes network traffic and thus can ascertain operating system type/version/patch level, installed application base/version/patch level, etc.)

I don't know of any research to point you to.

Obviously any automatic or manual upgrade process is fraught with peril, as it is essentially designed to be an endpoint for remote code execution. It would be nice if Google or Microsoft did a case study on how they architected their update systems. Obviously MSFT's went screwy with Flame, but I still think there's lessons we can learn.

To Michael's point, how these systems deal with rollbacks and network isolation is interesting. I've heard that Tor Project's Thandy is an implementation of a research paper that covers this and other topics, but I can't find a reference. Maybe someone can find it and provide one.

On 6 February 2013 11:23, Andreas Bader <noergelpizza@hotmail.de> wrote:

...

I think SL, Debian, Suse or CentOS are not less secure than ChromeOS. And if there is a secure problem then you have enough control to fix the system.

I disagree with this. All of those OS (I'm actually not sure of 'SL'?) do not do process isolation. If I get code execution in FF, I can compromise thunderbird. You are not able to 'fix' this except by rewriting the OS or doing some jinky hack to run every app as a separate user. Likewise, every app running is not written to the quality that Chrome Browser/ChromeOS is. Additionally, the OS and the applications are stewarded by different people, and the interface between those groups leads to bugs. Put a $100K bounty on exploiting a desktop app running in one of those OSs and see how quickly you get takers. And finally, I think most people who say "you have control to fix things" forget that the 'you' in this context is a person who does not write code (python even, let alone c), does not know what a partition table is, does not compile their own kernel, doesn't even have a compiler installed, doesn't understand the nuances of security - and just needs their computer to work.

-tom -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE