Chromium Blog: A sneak peek at the Native Client SDK(blog.chromium.org)
blog.chromium.org
Chromium Blog: A sneak peek at the Native Client SDK
http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html
7 comments
Done right, this will change the world. I'm currently working on porting an emulator. The major sticking point so far is the audio API, which seems rather primitive, but should be sufficient for my needs.
It seems to me that while this would have been interesting a few years ago, it's tied to x86 just as people are starting to browse the web more and more on mobile devices.
PNaCl is "write once, run on x86 and ARM". http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
FTA: "The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"
How does this differ from ActiveX controls in IE, aside from being cross platform?
NaCl hosts hacking contests asking people to break their sandbox: http://code.google.com/contests/nativeclient-security/
ActiveX asked users "are you sure you want to run this native code?".
ActiveX asked users "are you sure you want to run this native code?".
What would be the difference if Microsoft disabled the prompts for ActiveX controls?
ActiveX has no verifier.
NaCl is sandboxed; ActiveX is not.
ActiveX itself isn't sandboxed, but modern IE (and it's plugin hosting environment) is. Your comment is misleading.
You're right; I should have said "ActiveX ca. 2000 when I and everyone else gave up on it". If MS has fixed the implementation maybe they should change the name, because the ActiveX brand is irredeemable.
ActiveX can be sandboxed pretty strongly, but plugins can opt out of it. NaCl seems to leave no way to get out of the sandbox. I think Microsoft could easily add something very similar to NaCl to ActiveX, and then create a distinction in the UI between these sandboxed plugins and the current kind.
Edit: To clarify, ActiveX plugins cannot really "opt out" of IE's sandbox. There are some things they can do to reduce some of the default restrictions, but the most important ones always remain in place.
Edit: To clarify, ActiveX plugins cannot really "opt out" of IE's sandbox. There are some things they can do to reduce some of the default restrictions, but the most important ones always remain in place.
ActiveX's controls are nothing at all like NACL's.
NACL restricts the actual ABI. It enforces constraints that make disassembly to basic blocks deterministic (regular x86 isn't). It then uses the X86 MMU to prevent control flow blocks that could escape the sandbox.
Say whatever you want about ActiveX security (ActiveX is, for what it's worth, not secure --- though at some point all of IE might be), but they aren't doing basic block analysis, an MMU-enforced sandbox, or requiring special compilers for everything linked into the controls.
NACL restricts the actual ABI. It enforces constraints that make disassembly to basic blocks deterministic (regular x86 isn't). It then uses the X86 MMU to prevent control flow blocks that could escape the sandbox.
Say whatever you want about ActiveX security (ActiveX is, for what it's worth, not secure --- though at some point all of IE might be), but they aren't doing basic block analysis, an MMU-enforced sandbox, or requiring special compilers for everything linked into the controls.
It's been a long time since I read the NaCL publications so I might be forgetting some things. But, let's say IE9 were to move plugins to their own low-integrity processes (instead of being in the tabs' low-integrity processes like now). Given a perfectly-functioning mandatory integrity control system, how much of the additional NaCL infrastructure really provides extra security? How much of it "just" provides an extra layer of defense against kernel bugs and/or security for pre-Vista/non-Windows systems?
In other words, is this extra infrastructure something that Microsoft would really find useful to implement in IE9? Or, is it just needed for operating systems that IE9 won't support anyway?
In other words, is this extra infrastructure something that Microsoft would really find useful to implement in IE9? Or, is it just needed for operating systems that IE9 won't support anyway?
Because WinAPI, no matter what MAC system it implements, isn't enforced at the basic-block level, and NaCL is. NaCL has a smaller auditable attack surface. No matter what WinAPI does, the entire memory map of an x86-64 process is exposed to IE, and the same system call gates are exposed, and the same set of inherited process attributes are there.
I'm not saying one is more secure than the other (NaCL's model is more elegant but theoretically riskier, WinAPI's is better tested and more conservative).
I'm not saying one is more secure than the other (NaCL's model is more elegant but theoretically riskier, WinAPI's is better tested and more conservative).
How does ActiveX sandboxing work?
As far as I know, it mainly relies on signatures. What happens when you trust a control that has a bug which overwrites your hard disk? And that's leaving out malicious code...
As far as I know, it mainly relies on signatures. What happens when you trust a control that has a bug which overwrites your hard disk? And that's leaving out malicious code...
AFAIK, there is no "ActiveX sandboxing" per se. It is the same as the sandboxing techniques that are available to all Windows executables. But, also Internet Explorer runs in "Protected Mode" by default, so many of these sandboxing techniques get applied--by default--to plugins. See http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx.
This looks impressive for systems that are supported (Vista and up). I'm not entirely convinced that all attack vectors have been considered though.
They appear to have considered the obvious things: write and execute access to files and other resources from restricted processes, preventing harmful windows message behavior.
But would a process with low integrity have read access to every other resource with low integrity? Or is that further constrained by some other access control mechanism? Also, I don't think it's a feature for an unprivileged process to have registry access, though I understand there may be reasons for it.
It could also be argued that there is a larger attack surface for protected mode processes, because they can call any OS function, but are just denied when they don't have the access level to commit the action.
I must admit I am behind the times with regards to Windows system programming.
They appear to have considered the obvious things: write and execute access to files and other resources from restricted processes, preventing harmful windows message behavior.
But would a process with low integrity have read access to every other resource with low integrity? Or is that further constrained by some other access control mechanism? Also, I don't think it's a feature for an unprivileged process to have registry access, though I understand there may be reasons for it.
It could also be argued that there is a larger attack surface for protected mode processes, because they can call any OS function, but are just denied when they don't have the access level to commit the action.
I must admit I am behind the times with regards to Windows system programming.
Yes, one advantage of Chrome's system is that it can be more restrictive than the operating system. And, the pre-scanning is an extra line of defense.
I won't attempt to explain the integrity system in Windows because I am not that familiar with it. But, Wikipedia says that read access can be blocked based on integrity level too. See http://en.wikipedia.org/wiki/Mandatory_Integrity_Control
I won't attempt to explain the integrity system in Windows because I am not that familiar with it. But, Wikipedia says that read access can be blocked based on integrity level too. See http://en.wikipedia.org/wiki/Mandatory_Integrity_Control
As a final note, there's no reason why the two couldn't be used in tandem. In fact, they should be.
I think that Chrome and IE differ in how they split functionality between processes (and thus integrity levels), but both Chrome and IE make extensive use of the various sandboxing tools that Windows offers.
Very informative link. Thank you.
I am trying to understand this, if this is similar to activex, do we have to deal with annoying popup like "Do you want to install this activex plugin" for every webapps for chrome based on this?
Well, as wmf said, sandboxing is key. All NativeClient apps are compiled specially and scanned before they are run to ensure that apps can't use just any system call - they must interact only through NaCl's posix like library and the plugin api.
Their homepage has a paper and video describing this in detail: http://code.google.com/p/nativeclient/
[edit] Just realized I didn't respond to the meat of your post. Theoretically, there is no reason why any warning would be necessary for running a NaCl plugin because the sandboxing would be secure.
Their homepage has a paper and video describing this in detail: http://code.google.com/p/nativeclient/
[edit] Just realized I didn't respond to the meat of your post. Theoretically, there is no reason why any warning would be necessary for running a NaCl plugin because the sandboxing would be secure.
The main difference between Chrome's model and IE's model is that Chrome enforces restrictions itself, whereas the operating system enforces the restrictions for IE. I think IE's model works pretty well for Vista and later Windows systems. Chrome's model works for Windows XP and it also might be better for other operating systems.
That is misleading. An ActiveX control has the same permissions as the IE process hosting it. A malicious ActiveX control can hijack your browser, and do any number of other things.
A NaCl app can only interact with the system through a restricted syscall interface. That's it.
A NaCl app can only interact with the system through a restricted syscall interface. That's it.
The hosting IE process is running with low integrity. Accordingly, it's ability to do bad stuff is severely limited.
I do see that restricting access to syscalls potentially improves security. But, which syscalls can a low integrity process use to actually do something bad? That's something I'm interested in finding out.
I do see that restricting access to syscalls potentially improves security. But, which syscalls can a low integrity process use to actually do something bad? That's something I'm interested in finding out.
This is very true. The technical difference between sandboxed IE and NACL isn't as sexy or easy to explain as the grandparent comment. It's that NACL programs have a potentially smaller attack surface than IE; the NACL reference monitor is entirely contained in NACL, where IE's reference monitor is the whole OS.
Chrome's sandboxing is conceptually more secure than IE's, and NACL is more secure than sandboxed ActiveX. The key difference in both cases is granularity.
Chrome sandboxes each tab individually, whereas IE runs all tabs in the same sandbox. It's true that in both cases a malicious website could not cause much damage to the OS, but as more stuff moves into the browser it becomes more important that a malicious web app cannot mess with other web apps (tabs) that are open.
If a malicious website gains control over the IE sandbox, it has access to all web sessions within the sandbox. This is not true for Chrome.
Chrome, like IE, uses OS mechanisms for its sandboxing on Windows, most importantly restricted tokens. These have been around since Windows 2000 and are more powerful than the one dimensional integrity level introduced with Vista.
NACL is two steps ahead of ActiveX with regards to security. An ActiveX control running in the IE sandbox has immediate access to the whole sandbox (which includes all running tabs). Because of this, one would never run an untrusted ActiveX control, period. Hence the prompts and signature checks.
NACL on the other hand has two layers of defense, and each one would conceptually be sufficient to run untrusted content. The first layer is the native client sandbox (with the verified machine code etc.). The second layer is the per-tab Chrome sandbox described above. So even if a native client app breaks out of the native client sandbox, it would then have to break out of its tab's Chrome sandbox to do any damage at all.
Chrome sandboxes each tab individually, whereas IE runs all tabs in the same sandbox. It's true that in both cases a malicious website could not cause much damage to the OS, but as more stuff moves into the browser it becomes more important that a malicious web app cannot mess with other web apps (tabs) that are open.
If a malicious website gains control over the IE sandbox, it has access to all web sessions within the sandbox. This is not true for Chrome.
Chrome, like IE, uses OS mechanisms for its sandboxing on Windows, most importantly restricted tokens. These have been around since Windows 2000 and are more powerful than the one dimensional integrity level introduced with Vista.
NACL is two steps ahead of ActiveX with regards to security. An ActiveX control running in the IE sandbox has immediate access to the whole sandbox (which includes all running tabs). Because of this, one would never run an untrusted ActiveX control, period. Hence the prompts and signature checks.
NACL on the other hand has two layers of defense, and each one would conceptually be sufficient to run untrusted content. The first layer is the native client sandbox (with the verified machine code etc.). The second layer is the per-tab Chrome sandbox described above. So even if a native client app breaks out of the native client sandbox, it would then have to break out of its tab's Chrome sandbox to do any damage at all.
IE8 does sometimes put multiple tabs in one process, but not all tabs are in the same process. I think Microsoft should move to one-process-per-tab too; if Chrome can do it without any negative performance impact (AFAICT), so should IE. But, I'm not sure the rest of what Chrome does would be useful in IE. Microsoft wants to keep the security enforcement in the operating system so that all native applications can benefit from it. Google is happy to have lots of security enforcement in Chrome itself because it doesn't really care about the security of anything other than Chrome, and it cares about platforms that don't have the security features that Windows has.
In particular, one thing that's strange about NaCL is that plugin processes have stronger security than Chrome itself (unless Chrome is being built with the same or similar NaCL toolchain). In Microsoft's design, plugins are protected equally with the IE tab processes themselves, which seems very sensible to me, considering all the untrusted content that the browser itself has to interpret.
I would still like to know, theoretically, what Chrome's design stops that cannot be stopped using IE8's design, modified to have one tab per process.
In particular, one thing that's strange about NaCL is that plugin processes have stronger security than Chrome itself (unless Chrome is being built with the same or similar NaCL toolchain). In Microsoft's design, plugins are protected equally with the IE tab processes themselves, which seems very sensible to me, considering all the untrusted content that the browser itself has to interpret.
I would still like to know, theoretically, what Chrome's design stops that cannot be stopped using IE8's design, modified to have one tab per process.
IE8 does sometimes put multiple tabs in one process, but not all tabs are in the same process. I think Microsoft should move to one-process-per-tab too;
The problem is that all these processes run in the same sandbox (at the integrity level "Low"), so they are not protected from each other.
But, I'm not sure the rest of what Chrome does would be useful in IE
Again, like IE, Chrome itself uses OS mechanisms for the sandboxing.
In particular, one thing that's strange about NaCL is that plugin processes have stronger security than Chrome itself
This differentiation seems reasonable because Chrome itself is considered trusted code, whereas these plugins aren't.
I would still like to know, theoretically, what Chrome's design stops that cannot be stopped using IE8's design, modified to have one tab per process.
Since IE has one sandbox for all processes, one compromised tab could affect other tabs. Not so in Chrome. If IE switched to one process per tab and one sandbox per process, things would be more similar, but NACL in a Chrome sandbox would still be more secure than ActiveX in an IE sandbox because of NACL's additional layer of security. A NACL plugin would need to exploit weaknesses in both NACL and the Chrome sandbox in order to do any damage.
The problem is that all these processes run in the same sandbox (at the integrity level "Low"), so they are not protected from each other.
But, I'm not sure the rest of what Chrome does would be useful in IE
Again, like IE, Chrome itself uses OS mechanisms for the sandboxing.
In particular, one thing that's strange about NaCL is that plugin processes have stronger security than Chrome itself
This differentiation seems reasonable because Chrome itself is considered trusted code, whereas these plugins aren't.
I would still like to know, theoretically, what Chrome's design stops that cannot be stopped using IE8's design, modified to have one tab per process.
Since IE has one sandbox for all processes, one compromised tab could affect other tabs. Not so in Chrome. If IE switched to one process per tab and one sandbox per process, things would be more similar, but NACL in a Chrome sandbox would still be more secure than ActiveX in an IE sandbox because of NACL's additional layer of security. A NACL plugin would need to exploit weaknesses in both NACL and the Chrome sandbox in order to do any damage.
Will it work in non-chromium browsers?
It is open source, and could be adapted by any browser, AFAIK.
There was a FF plugin that was included in the research bundle. (although it never worked for me)
To what degree does "Embrace and Extend" apply to what Google is doing?
That's pretty vague. How does it apply to this situation?
The code is open; part of the NaCL API is designed around Posix/Linux; the Plugin API is the familiar NPAPI and its extensions.
Which part is proprietary or controlled by Google?
To my mind, some more relevant questions are: Does this tie the web to x86 (and ARM)? Can it be adapted securely to x86-64? Can it be made secure? Can multiple implementations be made secure?
The code is open; part of the NaCL API is designed around Posix/Linux; the Plugin API is the familiar NPAPI and its extensions.
Which part is proprietary or controlled by Google?
To my mind, some more relevant questions are: Does this tie the web to x86 (and ARM)? Can it be adapted securely to x86-64? Can it be made secure? Can multiple implementations be made secure?
> Can it be adapted securely to x86-64?
FTA: "a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"
FTA: "a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"
This looks horrendous. Watch the video for the hello world example. It's probably 100 lines of unintelligible code.
Miguel de Icaza's CLI for the web idea (http://tirania.org/blog/archive/2010/May-03.html) looks like a much better approach.
Miguel de Icaza's CLI for the web idea (http://tirania.org/blog/archive/2010/May-03.html) looks like a much better approach.
It doesn't really matter that the code is unintelligible. One can use higher-level languages on top.
What isn't so good is that NaCl targets the architecture of the host machine. So you're not going to be able to run a NaCl app compiled on x86 on a browser running under ARM. Someone please correct me if I'm wrong.
Miguel suggesting CLI isn't exactly surprising ;), but personally I'd prefer to use a sandboxed VM based on LLVM. CLI makes too many assumptions about the architecture of your language, whilst LLVM is more low-level.
What isn't so good is that NaCl targets the architecture of the host machine. So you're not going to be able to run a NaCl app compiled on x86 on a browser running under ARM. Someone please correct me if I'm wrong.
Miguel suggesting CLI isn't exactly surprising ;), but personally I'd prefer to use a sandboxed VM based on LLVM. CLI makes too many assumptions about the architecture of your language, whilst LLVM is more low-level.
You can compile your binary for multiple architectures, check the type of processor and give it the appropriate binary.
They also have the LLVM option so that old binaries keep working on new architectures without recompiling and rewriting NaCl for them, but it has downsides http://blog.chromium.org/2010/03/native-client-and-web-porta...
The reason they didn't go with LLVM as the main approach was performance. Google wants there to be no distinction between desktop and web apps, and for web apps to have even 60% of desktop performance is still unacceptable. 90+% is more like it.
They also have the LLVM option so that old binaries keep working on new architectures without recompiling and rewriting NaCl for them, but it has downsides http://blog.chromium.org/2010/03/native-client-and-web-porta...
The reason they didn't go with LLVM as the main approach was performance. Google wants there to be no distinction between desktop and web apps, and for web apps to have even 60% of desktop performance is still unacceptable. 90+% is more like it.
It's good to know that there's work being done in marrying LLVM to NaCl. Even 60% performance seems a very fair trade-off for low-level, platform-neutral, sandboxed binaries.
Regarding LLVM -- See the comment about PNaCl (Portable Native Code Client). This is portable code based on LLVM intermediate representation.
Go runs under NaCl - check out setting up a rendering context for a simple tetris game: http://golang.org/src/pkg/exp/4s/4s.go It's literally a couple of lines in the main function. Pretty straightforward.
I think the guys here chose a less-than-ideal way of demoing the interface for this video, which is surprising.
I think the guys here chose a less-than-ideal way of demoing the interface for this video, which is surprising.
You just have to port your CLI to native client and it's done, the ugly code is wrote once and then shared.
Also pretty interesting if you haven't read it (PDF): http://nativeclient.googlecode.com/svn/data/docs_tarball/nac...
Browsers are going to be getting closer and closer to the metal all the time. That's what this is telling us. It's like 1991 all over again.
Right. And in 1991, applications achieved much more of the potential performance and capability due to the available hardware than web apps do today. So going back to 1991 is an improvement in that respect. The rise of the web has been a trade-off - well-known and significant benefits have been realized, but at the cost of devolution and dead-ends in areas like the developer experience and UI flexibility. (As an example, think about all the reasons why World of Warcraft is not a web app.)