Cross-origin embedding: <embed> vs. <iframe>
Mark Seaborn
A criticism that I received in response to the file fetching design [1] was that it wouldn't work well for the use case of embedding NaCl programs across origins with the <embed> tag, e.g.
<embed src="http://a.com/foo.nexe" type="application/x-nacl-doodad"/>
Suppose this HTML appears on http://b.com.
My first question is: With whose authority is the NaCl process for foo.nexe intended to run? Does it run
* with origin b.com's authority (as with Javascript included cross-origin via a <script> tag),
* with origin a.com's authority (as with Javascript on a page embedded cross-origin via an <iframe>), or
* with some combination of the two (as it currently appears to be in the presence of http://code.google.com/p/nativeclient/issues/detail?id=238)?
If the NaCl process runs with a.com's authority, then there are no Javascript objects that the process can both communicate with and trust. This means that any Web API that is currently available to Javascript (e.g. XMLHttpRequest) will not be trustworthily available to the NaCl process unless a special NaCl-specific wrapper for the API is provided by the TCB. This is why cross-origin embedding with <embed> is problematic.
An alternative is to embed the NaCl program via an <iframe> pointing to HTML provided by a.com, which in turn launches a NaCl process. This has the advantage that the NaCl process can access DOM APIs (including fetching files) through Javascript on a.com's HTML page, and it is possible for the process to trust the interfaces that a.com's Javascript provides to it.
My question is: What is the rationale for wanting to embed a NaCl process cross-origin via <embed>? Why not use <iframe>s for cross-origin embedding instead?
Mark
[1] http://code.google.com/p/nativeclient/wiki/AcquiringDynamicLibraries
Here is the next design doc on dynamic libraries, specifically on how to handle fetching library files. It follows on from the previous doc on dynamic loading. In short, I propose to implement open() as an RPC which can be handled by untrusted code (Javascript or NaCl code) to provide a private file namespace to the web app:
http://code.google.com/p/nativeclient/wiki/AcquiringDynamicLibraries
The following page will be the top-level design doc from which I will link the others:
http://code.google.com/p/nativeclient/wiki/DynamicLinkingPlan
Feedback welcome, as before!
Mark
Cliff L. Biffle
> A criticism that I received in response to the file fetching design [1] was
> that it wouldn't work well for the use case of embedding NaCl programs
> across origins with the <embed> tag, e.g.
I was at least one of the sources of this. My criticism was less on
which particular HTML tag is used for the embed, and more on whether
the executable contained sufficient information to be run. This was
based on an example that showed the HTML author -- not the developer
of the module -- having final say on which dynamic library
implementations get loaded, and perhaps even on details of the address
space layout. Both of these seem like bad ideas to me. As an
application author, the last thing I want is for other people to
surprise me with new libraries. The stability programs caused by
Windows antivirus software are a great example of what can happen
here. Factor in malicious libraries chosen for your app on pages
controlled by people-who-aren't-you, and this starts to sound scary.
I understand the argument that the NaCl module should not get to have
final say on the library sources because it's an unacceptable level of
ambient authority -- I just disagree with it. :-) If the application
can specify libraries by path (not URL) in its headers, and the
hosting server is the only place searched, things get more reliable.
Allowing the server to host whitelists restricting what paths
nexes/libraries can be served from resolves most of my security
concerns (idea credit: bsy).
As for IFRAME vs. EMBED, they both have their strengths and
weaknesses, but the origin policy for IFRAMES seems far more
clear-cut, so that seems like a fine solution. Just remember that
there's little to *stop* a third-party from presenting your module
using EMBED, so we should have sane degradation when it happens.
--
Cliff L. Biffle
Google, Inc.
(650) 253-1473
Victor Khimenko
If the application can specify libraries by path (not URL) in its headers, and thehosting server is the only place searched, things get more reliable.
Allowing the server to host whitelists restricting what paths
nexes/libraries can be served from resolves most of my security
concerns (idea credit: bsy).
Cliff L. Biffle
> And immensely less useful too. This will mean the only way to host small
> extension to NaCled perl will be if you'll host the whole CPAN too...
I'm not proposing this as the endgame, just as a sufficiently flexible
solution for v1 with room for us to loosen it later.. Today, you
would have to compile all of CPAN in.
Mark Seaborn
On Fri, Jan 15, 2010 at 12:11 PM, Mark Seaborn <msea...@chromium.org> wrote:I was at least one of the sources of this. My criticism was less on
> A criticism that I received in response to the file fetching design [1] was
> that it wouldn't work well for the use case of embedding NaCl programs
> across origins with the <embed> tag, e.g.
which particular HTML tag is used for the embed, and more on whether
the executable contained sufficient information to be run. This was
based on an example that showed the HTML author -- not the developer
of the module -- having final say on which dynamic library
implementations get loaded, and perhaps even on details of the address
space layout. Both of these seem like bad ideas to me. As an
application author, the last thing I want is for other people to
surprise me with new libraries. The stability programs caused by
Windows antivirus software are a great example of what can happen
here. Factor in malicious libraries chosen for your app on pages
controlled by people-who-aren't-you, and this starts to sound scary.
Are you talking about enforcing security properties, or more general engineering concerns (such as the "ship the bits you test" principle)?
The mechanism you're suggesting -- ensuring the executable is self-sufficient and contains all the information it needs to run -- suggests that you are assuming a particular trust relationship between the embedder and embeddee, namely that the embeddee can have more authority than the embedder.
If, on the other hand, the embeddee only receives authority from the embedder, there is no problem with malicious libraries. The embedder has no need to trick the embeddee, because the embeddee has no more authority than the embedder.
This is what I was trying to clarify: which trust relationship do you have in mind?
I don't know enough about how anti-virus software works on Windows to know how this is related. Can you explain?
On address space layout: yes, I did suggest that there could be parameters for configuring this when launching a NaCl process via a programmatic interface. The example was:
dynamic_linker_fd = fetchFromUrl(".../ld.so.2")
process = makeNaClProcess(
{executable_fd: dynamic_linker_fd,
code_region_size: 0x100000, ...})
There are actually a number of things we might want to pass in or make configurable at process creation time:
* Size of stack: We cannot grow the stack dynamically because we cannot catch page faults. We have to reserve address space up front, but one choice will not suit all applications. Address space is more limited under NaCl so some apps may wish to allocate a smaller stack for the initial thread to avoid wasting address space.
* Size of code region: The amount of address space reserved for dynamically loaded code under a ContiguousCode scheme. This can't be changed after the process has been started.
* Arguments to the process (argv and environment variables).
* Initial array of file descriptors.
There is a question of whether these parameters are specified by programmatic interfaces or file formats (e.g. ELF headers), or are not configurable at all. I favour programmatic interfaces. Clearly file descriptors cannot be specified in a config file.
I understand the argument that the NaCl module should not get to have
final say on the library sources because it's an unacceptable level of
ambient authority -- I just disagree with it. :-)
If the application can specify libraries by path (not URL) in its headers, and the
hosting server is the only place searched, things get more reliable.
Allowing the server to host whitelists restricting what paths
nexes/libraries can be served from resolves most of my security
concerns (idea credit: bsy).
Could you sketch out some more details of this idea? Do you have in mind a magic per-server file, similar to Flash's crossdomain.xml, for specifying these whitelists?
As for IFRAME vs. EMBED, they both have their strengths and
weaknesses, but the origin policy for IFRAMES seems far more
clear-cut, so that seems like a fine solution. Just remember that
there's little to *stop* a third-party from presenting your module
using EMBED, so we should have sane degradation when it happens.
We could stop <embed> from working cross-origin and say that <iframe> must be used instead.
The rules about which content types are exposed cross-origin are complicated enough already. e.g. <script> means that the browser has a special exception for text/javascript, which has caused problems. It would be better not to add more exceptions, and instead use the newer cross-origin URL-fetching APIs where content types are treated consistently.
Cheers,
Mark
Bennet Yee (余仕斌)
web authors -- who know javascript but probably nothing about linker
scripts -- to have to dive into that level of details will make NaCl
embedding less useful.
while it may be possible to wrap all this complexity with a javascript
library, i don't think that's the right answer either. casual games
that have game assets, for example, will want to make it easy for
others to embed the game -- along with the game assets -- in their
pages. the requirement that dynamic libraries and files must be
loaded from the domain of the container forces embeds to be iframes,
which is too constraining. would casual game publishers have to
explicitly waive copyright for the game assets so that embedding sites
can make a copy? how could the game be updated? suppose it needs new
assets? new dynamic libraries? would all embedding sites need to be
informed of pending updates, so that they can all fix their code?
-bsy
> --
> You received this message because you are subscribed to the Google Groups
> "Native Client Discuss" group.
> To post to this group, send email to native-cli...@googlegroups.com.
> To unsubscribe from this group, send email to
> native-client-di...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/native-client-discuss?hl=en.
>
>
--
bennet s yee
i usually don't capitalize due to mild tendonitis
Mark Seaborn
i think it is a mistake to make our system less usable. and requiring
web authors -- who know javascript but probably nothing about linker
scripts -- to have to dive into that level of details will make NaCl
embedding less useful.
I'm not sure what part of my post you are responding to here.
while it may be possible to wrap all this complexity with a javascript
library, i don't think that's the right answer either. casual games
that have game assets, for example, will want to make it easy for
others to embed the game -- along with the game assets -- in their
pages. the requirement that dynamic libraries and files must be
loaded from the domain of the container forces embeds to be iframes,
which is too constraining.
Why are iframes too constraining?
would casual game publishers have to
explicitly waive copyright for the game assets so that embedding sites
can make a copy? how could the game be updated? suppose it needs new
assets? new dynamic libraries? would all embedding sites need to be
informed of pending updates, so that they can all fix their code?
These questions are all assuming the game is not embedded via an iframe, aren't they?
Mark
Bennet Yee (余仕斌)
> On Wed, Jan 27, 2010 at 10:04 PM, Bennet Yee (余仕斌) <b...@google.com> wrote:
>>
>> i think it is a mistake to make our system less usable. and requiring
>> web authors -- who know javascript but probably nothing about linker
>> scripts -- to have to dive into that level of details will make NaCl
>> embedding less useful.
>
> I'm not sure what part of my post you are responding to here.
i'm replying to both the notion of not allowing nacl modules to load
assets hosted at the same location as the nacl module and to the
dynamic loading memory layout proposal, which i believe you had also
mentioned via the code snippet w/ the dynamic_linker_fd code snippet,
as well as via the footnote in the first message in this thread.
>
>>
>> while it may be possible to wrap all this complexity with a javascript
>> library, i don't think that's the right answer either. casual games
>> that have game assets, for example, will want to make it easy for
>> others to embed the game -- along with the game assets -- in their
>> pages. the requirement that dynamic libraries and files must be
>> loaded from the domain of the container forces embeds to be iframes,
>> which is too constraining.
>
> Why are iframes too constraining?
can you easily coordinate actions between javascript code in a page
and those in a contained iframe with content loaded from a different
domain? can you make SRPC calls into a NaCl module embedded within an
iframe, again with content from a different domain?
>
>>
>> would casual game publishers have to
>> explicitly waive copyright for the game assets so that embedding sites
>> can make a copy? how could the game be updated? suppose it needs new
>> assets? new dynamic libraries? would all embedding sites need to be
>> informed of pending updates, so that they can all fix their code?
>
> These questions are all assuming the game is not embedded via an iframe,
> aren't they?
>
> Mark
>
>
--
Mark Seaborn
On Wed, Jan 27, 2010 at 2:23 PM, Mark Seaborn <msea...@chromium.org> wrote:
> On Wed, Jan 27, 2010 at 10:04 PM, Bennet Yee (余仕斌) <b...@google.com> wrote:
>>
>> i think it is a mistake to make our system less usable. and requiring
>> web authors -- who know javascript but probably nothing about linker
>> scripts -- to have to dive into that level of details will make NaCl
>> embedding less useful.
BTW, linker scripts are not involved. We are talking about fetching and loading executables/libraries, at which time the executables/libraries have already been linked.
> I'm not sure what part of my post you are responding to here.i'm replying to both the notion of not allowing nacl modules to load
assets hosted at the same location as the nacl module
Would you like to make a proposal for how that would be handled?
I am not against NaCl processes being able to fetch same-origin or cross-origin URLs per se. The issues for me are:
* Is the ability to fetch URLs either received ambiently (e.g. a special system call like open()) or as a descriptor that all processes are given on startup? If so, this would make it difficult to create sandboxed NaCl processes that don't have network access. It would be difficult for a site to host guest code that it does not trust (the use case that Caja supports for Javascript code).
* Will fetching from a URL use the browser's cookies for the URL's origin?
* Will fetching URLs use the same access control semantics as an existing URL-fetching scheme, or will introduce new access control semantics?
The context of the last question is that there are multiple DOM interfaces for fetching from URLs already existing or being proposed, all with different access control semantics:
* XMLHttpRequest: same origin, applies cookies (uses ambient authority)
* CORS: cross-origin, applies cookies (uses ambient authority)
* Uniform Messaging: cross-origin, does not apply cookies
* Internet Explorer's non-standard XDomainRequest (don't know the details about this one)
Adding to this list should not be done lightly because it has the potential to make web security more complex and harder to analyse.
and to the dynamic loading memory layout proposal, which i believe you had also
mentioned via the code snippet w/ the dynamic_linker_fd code snippet,
as well as via the footnote in the first message in this thread.
can you easily coordinate actions between javascript code in a page
>> while it may be possible to wrap all this complexity with a javascript
>> library, i don't think that's the right answer either. casual games
>> that have game assets, for example, will want to make it easy for
>> others to embed the game -- along with the game assets -- in their
>> pages. the requirement that dynamic libraries and files must be
>> loaded from the domain of the container forces embeds to be iframes,
>> which is too constraining.
>
> Why are iframes too constraining?
and those in a contained iframe with content loaded from a different
domain? can you make SRPC calls into a NaCl module embedded within an
iframe, again with content from a different domain?
Is anything wrong with postMessage() for this purpose?
Note that postMessage() can send MessagePorts, so it can be used to establish a connection between the embedding page and the embedded NaCl process. Hence these two can communicate without having to proxy all messages through the embedded page that launches the NaCl process.
Mark