

Native Client: Google's craziest idea yet - ccraigIW
http://weblog.infoworld.com/fatalexception/archives/2008/12/native_client_g.html

======
kragen
This article is really terrible. It spends half of the article before
mentioning the actual contribution of Native Client, which is that it securely
sandboxes C programs with little effort on the programmer's part, confuses
source code analysis with object code analysis, talks about memory
virtualization for security as if it had been invented in 2008 instead of
~1965 (and as if it weren't already a feature of every mainstream OS), glosses
over the API differences and the difficulty of designing a secure OS API, and
confuses Intel (one ARM licensee) with ARM.

In summary, it is an unreliable article written by someone without a clue.

------
Retric
Like VMware this is all based on problems with existing operating systems. I
should be able to download, install, and run any application from anybody
without compromising my system or adding much bloat. That's the real problem
that needs to be solved and I think the first group that get's this working is
going to become extremely wealthy.

PS: When you think about it VMware is one of the few operating systems that
has real working security, but I wonder how much else an OS can do while still
providing that level of safety and efficiency.

~~~
te_platt
"Any application" would have to include applications that compromise your
system.

For example, suppose you want an application that deletes any files on your
hard ending with tmp. I offer it for download, you get it, run it, like it.
Now (just because I can) I change the application (without telling you) to
delete all files ending with doc. You've been compromised.

~~~
stcredzero
If "Open File" (which may or may not mean a dialog) is a service provided by
the Operating System, then there is no reason why a sandboxed application
would have access to anything more than the particular file you have open.

People have been researching other security models for decades now. I'm afraid
I have to say: they're way ahead of you!

~~~
te_platt
Right, but then you are only including applications that have limited access
to files, not any application. I was just lured into a good paradox. :)

~~~
stcredzero
In such schemes, all applications have limited access to files. Again, these
guys are way ahead of you.

~~~
kragen
Not true; in KeyKOS, for example, the shell had full access to all the files
the user had access to, because that is where the user held the keys of their
directories. In CapDesk the window system has the same role. In general you
need to be able to run "utility" programs like the tmp-remover in the example.

That doesn't necessarily mean the author of the utility programs has to be
able to send updates without your approval, or that they need to be able to
receive communications from their utility program, or that you can't delegate
your approval of application updates to a third party who vets the code, or
that the utilities can't be small and clear enough that you don't have any
doubt about what they're doing, or that all programs need to have full access
to your files, or that you can't store your files somewhere where you can roll
back undesired deletions.

~~~
stcredzero
In those cases, the security schemes are somewhat weak. A proper sandboxing
scheme wouldn't need a .tmp file remover. Once you removed a given
application, all of the .tmp files it produced would just disappear with it.

The only reason you'd want to run such a utility would be to clean out the
.tmp files within a particular sandbox. In that case, you'd give permission
for it to operate on the whole of that particular sandbox's contents. Worst
case, it trashes that sandbox, then you roll back to your previous backup.

They were supposed to have a sandboxing scheme along these lines in the OLPC.

~~~
kragen
If you think KeyKOS's security scheme was "somewhat weak", you should read the
DTOS review of it (in [http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-
docs/...](http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/final-
docs/mer.pdf)), which was mostly positive. It includes a pretty balanced
picture of its pluses and minuses, although it doesn't seem to have been based
on experience actually using KeyKOS.

If your files belong to your applications instead of to you, or if your
sandboxes don't nest, then your sandboxing scheme is pretty lame.

Most of the time there are worse cases than just deleting your documents: the
utility could send all of your documents to its owner over the internet. You
can prevent this with sandboxing policies too; KeyKOS solved an analogous
problem in the context of a multiuser non-networked mainframe. More difficult
is to keep it from inserting backdoors into your programs or subtly corrupting
your files.

I don't see how the solution "then you roll back to your previous backup" is
dependent upon only the utility only having access to a single sandbox. It
seems like it works just as well if you give it access to everything except
your basic UI (and the TCB it depends on, e.g. the kernel, the bootloader) and
your backups.

~~~
stcredzero
Ah, so you're talking about capabilities? I thought you were arguing in favor
of the other guy's position -- that there's nothing you can do about malicious
apps. (And maybe in the face of ignorant and gullible users, there ultimately
is nothing, but lets leave social engineering out of this for now.)

I just didn't want to explain capabilities for the nth time, so I thought I'd
throw the OLPC at him. Even a sandboxing scheme like the OLPC's addresses his
objections. Not sure if it was supposed to nest.

~~~
kragen
There are lots of ways of implementing sandboxing; I think capability systems
are the most elegant and flexible, but I don't know for sure that they are the
best way, given that the judge is the messy real world, not mathematical
abstractions.

I was arguing that the other guy was right that sandboxing in itself is not
sufficient; you still do need to have a way to deal with code that you give
the full run of your system, even if you keep the amount of that code to a
minimum.

------
tjpick
I just don't get this stuff. The browser just isn't a great place to be
running applications like that. It's a good place for consuming document based
data. At the point where you have delivered an application that doesn't need
to transfer any data as html-over-http, why would it be running inside the
browser?

Maybe it's just that quake is a bad example use of this technology.

~~~
sadfsa
Right now, there is a Web site (pogo.com) where people actually pay money to
play pointless, boring games (such as Solitaire, Mahjong, etc), all of which
are written in Java.

A similar Web site, using Native Client, could roll out higher quality games
(like Quake) and charge higher prices for access.

------
tlrobinson
_" The code runs on the actual processor"_

...as opposed to... magic?

(and yes, I understand what he means, I just found it amusing)

------
jderick
Great idea.. clearly Google has its eyes set on the OS market. First, move as
much stuff to the cloud as you can, then open up NC for legacy apps.

------
clay
"this method leaves many handheld devices in the cold, including those based
on Intel's ARM chips."

haha

~~~
jpd
What's funny about that? It's a real issue and the first thing I thought of
when I head them say "native x86". Consider that there are also netbooks that
have ARM architecture as well (unless I'm mistaken).

Or are you referring to only the last 3 words? Intel's ARM chips?

~~~
kragen
It could be a problem for device vendors, but it shouldn't be a problem for
web sites that want to serve ARM9 devices with MMUs, such as Intel's
StrongARMs; the Native Client approach will work fine on ARM, although it will
take some work to make it happen. The bit about "Intel's ARM chips" is pretty
goofy, though.

------
newt0311
One question: If they are using 80386 memory segments, how do they cope with
systems like AMD64 and the linux kernel both of which have flat memory
systems? Besides, normal desktop OSes already isolate programs in their own
memory segments. Its the device access permissions and systems syscall
accesses that cause all the problem with secure object code usage.

------
Tichy
uh, no thanks!

------
Ben65
Yawn! I hate it when people link anything from infoworld.

