User: Password:
Subscribe / Log in / New account

Google's Native Client

Google's Native Client

Posted Jun 4, 2009 3:11 UTC (Thu) by jake (editor, #205)
In reply to: Google's Native Client by zooko
Parent article: Google's Native Client

> I disagree with your overall summary, Jake.

Hmm, interesting. I don't find much that I disagree with in your message, so either I didn't communicate well (likely) or your disagreement is not in an area that I considered to be central to the article.

I think it is a promising strategy to try to confine programs to doing "what we want", but that is a horribly difficult and error-prone process.

I guess you are more optimistic than I about removing the parser/loader/system call gate bugs in any kind of near-term timeframe. The side-channel attacks exist, and could be problematic, but that is just a demonstration of an inherent, architectural weakness of the scheme. The real problems are likely to come from all of the rest of it.

Bottom line, for me, is that I think I am about as likely to run NaCl binaries from untrusted sources anytime soon as I am to run ActiveX controls. Maybe I am behind the times, though.


(Log in to post comments)

Google's Native Client

Posted Jun 4, 2009 4:02 UTC (Thu) by elanthis (guest, #6227) [Link]

I see no reason not to have a hybrid approach. I like signed binaries not because it tells me that everyone who touched it was a Good Guy, but because it lets me know who (or which organization, at least) is vouching for the code. I trust the Linux kernel sources to be the foundation of my security-sensitive systems. That doesn't mean I trust every person who's touched the code, but it does mean that I trust the people reviewing and signing off on the code. And I want to know that my system is running an unmodified version of official Linux (or an unmodified distribution kernel, at least) and not some random hacker-supplied version.

That's where code signing comes in. It tells me that yes, this is the version of FooApp that I meant to download and run, and that yes, it really is from FooSoft.

What code verification does is an extra step to help protect me for cases when I find need to run code from some specific (but not yet fully trusted) software provider. I've never run anything from FooSoft before, but I find myself needing to run FooApp because it is the only software that does what I need. I'm not going to do a full source analysis (be honest, you almost certainly haven't even looked at the source for 99% of the software you run) because I have better things to do with my life. So I rely on code verification (like Google's) along with the positive reputation of FooSoft (and the fact that I know the FooApp I'm about to run really is the real deal from FooSoft) to keep me safe.

I can't guarantee I'm 100%. You can never do that. I might even have a box with no Internet access but my assistant/wife/janitor/whoever might decide to abuse his or her physical access.

ALL security -- be it computer security, a deadbolt, or whatever -- is about risk management. You can never completely remove security holes, but you can reduce the ease of finding them, increase the complexity to utilize them, and decrease the potential damage of abusing them.

Sandboxing, code verification, and code signing all are tools to help manage risk. No one method is fail proof and no one method is better than all methods.

Google's Native Client

Posted Jun 4, 2009 8:29 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Yeah. But automatically trusting your computer to trust anybody Microsoft (or Google, or whatever) trusts well enough to grant a certificate is a bit too many levels of indirection of trust.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds