Security in Native Client Is Lock Tight

By Clint Boulton  |  Posted 2008-12-11 Print this article Print

Q: What is Native Client and why function-targeted extensions (such as Google Gears) cannot fill the gap for specific horizontal scenarios?

Bridge: We view Native Client as a function-targeted extension. Basically, what Native Client is, is a technology for allowing Web developers to get access to the enormous computational power that exists on users' machines today. There's a significant gap today between the computational performance you can achieve with a program running natively on a machine and what you can do via JavaScript in a Web browser. So, really we're trying to bring that power to developers so that they can create new types of applications that employ native code. We released this this week is that it was at a stage that we felt like it was ready to share with the open-source community and the security community to get feedback from them. We want the security community to really try and break out of it so that if we decide to incorporate it inside a product down the line we've hopefully addressed the security issues in the technology. The security community on the Internet and the open-source community have a great history of finding things that are incredibly obscure.

Q: When we're dealing with Web applications, security is always a concern, but why is this such a big concern with Native Client?

Bridge: Native code is generally viewed as very scary. Native code is what the applications on your computer run right now and that means when it's installed on your computer it has access to the underlying parts of your system, such as the hard drive and the network subsystem. It allows applications to do scary things like erase your hard drive or spread malware over the network. The approach that we've taken with Native Client is that we've only allowed the native code to run on these models to do a select set of things, so you can't access the network or the files on the computer. It keeps users safe from all kinds of security concerns.

Q: So what did you do to lock up the native code for Native Client? [Warning: the following answer is best enjoyed if you're a developer].

Chen: Native code modules typically have full access to the operating system interface and that's the way they get access to the network and file system. In the Native Client container, we give the native code module access to the browser, so it can interact with the browser the same way JavaScript with the browser, that is safely interacting with the DOM and such. The system prevents the native code module from interacting with the operating system. What we need to implement is reliable disassembly of x86 code and that's sort of like the holy grail if you will, or the very difficult problem that other people have sometimes considered not possible. We basically set up a set of rules and have a static validator that dissembles the code and is able to check that the rules are followed and because the rules are followed, we're able to check that we're getting reliable disassembly. Then we can determine which instructions we do allow or do not allow in the native code module.

Upson provides a high-level answer for us non-geeks: With modern programming techniques, it's very hard to know what a program does, and that makes it difficult to say whether something is going to do something bad to your machine. Basically what we've done with Native Client, is made it so that with the native client module, you can't do a lot of the tricky things that make it difficult to understand what the program is doing. You can only do the core functionality of what the programs are allowed to do. That allows us to look at it and see whether it is going to do something dangerous.


Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel