NaCl sandboxed code does not use native system calls. If it did, running a NaCl program would be just as bad as running an ActiveX control.
NaCl programs are restricted by the verifier so that they can only run a set of virtual system calls defined by Google. That system call file is like its own cross-platform OS interface, like NSPR except for desktop programs.
When NaCl loads your program (which, remember, it wants to do without asking you), it forks a "secure ELF loader" program, which populates the first 64k bytes with a runtime (think crt0, on steroids), which we call the "trusted code base". The TCB isn't verified the same way the NaCl binary is, because it's code that Google wrote that never changes.
That code implements or trampolines to a common set of systemy things NaCl wants to let NaCl programs do. We made the comparison in that post between the NaCl runtime/TCB and the JVM applet sandbox, and I think it's apt. In both cases, you have a wad of code that is trusted by the system and needs to be bug free, and in both cases that's the first place a security researcher is going to look for flaws once the system is mature.
As I understand it now, NaCl is really just a way to offload CPU-bound tasks to native code with minimal overhead. It's interesting, but I'm not sure I like the trade-offs vs. a platform actually designed from the start to insure confinement of untrusted code (i.e., Java).
[1] -- Does anyone know of good literature on confinement of GPU-intensive code? I've read up x86 and Java security issues, but don't know of any good work on the security profile of code using OpenGL or DirectX...