5 ms·

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 syste

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/ 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.

briansmith 16y ago
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.
- enneff 16y ago
  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.
  - briansmith 16y ago
    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.
    - tptacek 16y ago
      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.
      - skuzins 16y ago
        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.
        briansmith 16y ago
        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.

briansmith 16y ago

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.

enneff 16y ago
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.
- briansmith 16y ago
  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.
  - tptacek 16y ago
    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.
    - skuzins 16y ago
      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.
      - briansmith 16y ago
        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.