[liberationtech] Chromebooks for Risky Situations?

[T N]

On Thu, Feb 7, 2013 at 4:46 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:

> As I said in another thread, I hadn't seen that they supported any VPN
> endpoints; my original ChromeOS device had no VPN support at all. I'm
> glad to see that they support IPSEC and OpenVPN (gladly no PPTP!).
> Ideally, I would like to see them offer an SSH setup wizard where it
> also uses OpenSSH as a VPN transport.
>
> I plan to look into their VPN setup - I would love to see that they're
> not vulnerable to the issues in our recent vpnwed paper.
>

AFAICT, they are doing a bunch of work on expanding VPN support so
enterprises can adopt the product.

The ssh client is "interesting", check it out if you haven't.  It's openssh
in NaCl form, running inside of hterm (javascript terminal).  One claim I
saw them make was this is more secure than a typical ssh client (running
off a linux distro, say) because in addition to the careful stuff done to
avoid any possibility (cough) of a javascript exploit, the whole caboodle
is running inside of a sandbox (because inside Chrome).  I don't know what
to make of that.  Various key management, tunneling and other support has
AFAICT been coming along.



> Weaponizing an exploit and persisting something malicious aren't the
> same problem. Consider a Chrome extension that logs all the urls one
> visits in the browser, will the ChromeOS security model prevent it?
>

I see what you're saying.  Yes, the "ironic" thing about Chrome OS is that
the base OS is relatively secure, but all of that is to force you into a
browser ("web world").  What exactly does one say about that!?  A giant
step forward in a commercial OS/hardware hardening effort, and a giant
regression?  Eh, the web still scares me.  Therapy hasn't helped.  Anyways
for a journalist in certain situations, connecting to say Google Docs...
using two factor authentication... in the spirit of what started this
thread, it seems like compared to a lot of off the shelf alternatives, this
is still a giant leap forward in terms of security.  It is at the very
least an interesting debate/thing to think about (per the thread)?


> I think you're seriously missing the point here.  My remarks were well
> > qualified.  Conditionals have to met:
> >
> > - IF you want low cost (time is money, so efforts to set up a Linux
> secure
> > laptop that are time consuming are expensive, as is all the time you
> spent
> > to learn how to do these things in the first place)
>
>
> Download Tails and boot it up.
>

Really though?  "Mr. Rather, could you please download tails and boot it
up?"

"Mr. Koppel, if you have a problem with this thing I'm handing you, contact
me, I'll get a hold of the mailing list..."

I'm being facetious of course.  And I think this gets into an interesting
area about how to support secure liberation technology.  That I don't know,
so not entirely sure what to say to what you suggest.



> > - IF you want a somewhat naive user to use the device (eg. journalist)
> > - etc.
>
> Ditto.
>
> I train journalists all the time and the only people who have issues are
> journalists with Macbooks, as there is a specific problem with new apple
> hardware and booting from a USB disk. In those cases, a DVD is read only
> and does just fine.
>

Okay, that's your experience.



I'd suggest users have no hard disk and boot off of a Tails USB disk.

Now we've reduced the attack surface to the BIOS/EFI layer - something
> that I suspect is pretty crappy all across the board.
>
> While ChromeOS will complain if it is shut down, I remember that it
> won't complain about being in Developer mode if it wakes from sleep.
> Thus, it is totally possible to hand someone a compromised ChromeOS
> device that is awake, let them login and you've won without even having
> to reflash the core OS.


Are we really trying to defend against that threat model?

Re your next email, I'll address one point, though spending this time
defending Chrome OS seems a bit silly.  I'm not a shill for Google and have
nothing to gain here (and thus at some point better things to do! :-).
 What I would say is to really go (again?) to chromium.org and look at all
the lengthy discussion of their security design.  Anywho, if the dev switch
is flipped, one has root without so much as a password (until one is set).
 But so what?  Dev mode only takes effect after the switch is flipped and
machine is boot (or reboot).  In other words, gaining root on an acquired
device gets you no closer to any cached data or credentials on the Chrome
OS device, because that stuff is all encrypted and being root doesn't help
you there, the user has to be logged on in and *active* session for root to
have any access to their data.  But if the user is active, the user is
right there physically and thus the threat model is again totally
different.  The Chrome OS documentation goes into quite a bit of detail
about what threat models they can and can't defend against.  The point I
would make here is gaining root on a Chrome OS device doesn't get you
anywhere unless the user is currently logged in on an active session, and
that's not possible unless the user is right there or walked away from the
machine in the middle of using it without locking their screen (locking
screen unmounts the decrypted home directory- ie. encrypts everything),
logging out, or powering down.  But if the user did that, few things are
able to defend against that!

Trever
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130207/67f9b4ed/attachment.html>