Fwd: [native-client-discuss] iframe sandbox attribute vs. PNaCl

25 views
Skip to first unread message

Darin Fisher

unread,
Oct 7, 2014, 12:41:35 PM10/7/14
to Mike West, Adam Barth, peppe...@chromium.org
It seems reasonable to still allow a PNaCl module to load since they are like origin restricted scripts. We treat PNaCl code like script, rather than like plugins, in a lot of other contexts. We should do the same thing here?

-Darin


---------- Forwarded message ----------
From: Soeren Balko <soe...@zfaas.com>
Date: Tue, Oct 7, 2014 at 6:24 AM
Subject: [native-client-discuss] iframe sandbox attribute vs. PNaCl
To: native-cli...@googlegroups.com


Hi Google,

I noticed what I consider a bug when embedding PNaCl from within an iframe. When using the sandbox attribute and setting it to "allow-same-origin allow-scripts", the <embed> element within the iframe's document (loaded from another origin) fails to fetch the nmf file, and hence also doesn't load the actual PNaCl module. When I drop the "sandbox" attribute, the nmf file and PNaCl modules load just fine. As I understand the "sandbox" attribute was introduced to security-constrain code running in the iframe. Is there some extra property that needs to go into the sandbox attribute value (besides "allow-same-origin" and "allow-scripts")?

Soeren

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

Mike West

unread,
Oct 7, 2014, 12:49:04 PM10/7/14
to Darin Fisher, Thomas Sepez, peppe...@chromium.org, Adam Barth

I'm inclined to agree, but there are some edge cases. Pepper Flash, for instance, can be granted permission to escape that script-like state in a few ways.

But we should be able to find a way to make sandboxes plugins generally work in the same way that script does.

+tsepez, as I know I've talked to you about this in the past.

-mike

Darin Fisher

unread,
Oct 7, 2014, 12:55:32 PM10/7/14
to Mike West, Thomas Sepez, peppe...@chromium.org, Adam Barth
Right. I believe there's a flag that Pepper Flash and other "trusted" pepper plugins use to indicate that they are not origin restricted. We should be able to key off of that.

-Darin

Darin Fisher

unread,
Oct 8, 2014, 4:59:26 PM10/8/14
to Mike West, Thomas Sepez, peppe...@chromium.org, Adam Barth, ncb...@chromium.org
joining the streams...

Nick Bray

unread,
Oct 8, 2014, 5:03:15 PM10/8/14
to Darin Fisher, Mike West, Thomas Sepez, peppe...@chromium.org, Adam Barth, ncb...@chromium.org
So, is the official word that plugins of any sort are currently not supported in sandboxed iframes, but we may be able to loosen this in the future for PNaCl?

Darin Fisher

unread,
Oct 8, 2014, 5:07:54 PM10/8/14
to Nick Bray, Mike West, Thomas Sepez, peppe...@chromium.org, Adam Barth, ncb...@chromium.org
Yes, basically. I think any pepper plugin that is same origin restricted can be treated more like script. Maybe that is equivalent to PNaCl.

-Darin

Mike West

unread,
Oct 8, 2014, 11:36:11 PM10/8/14
to Darin Fisher, Nick Bray, Thomas Sepez, peppe...@chromium.org, Adam Barth, ncb...@chromium.org
I took a quick look at the current sandboxing implementation: we do sandbox checks on <object> in Blink (in HTMLPluginElement::pluginIsLoadable) before the request is actually fired. We don't actually know what kind of plugin we'll be loading when we're making the decision.

To support this change, we'd need either to pipe sandboxing state up into the embedder along with the request, or move the check somewhere later in the plugin's loading process. Either seems doable, but non-trivial.

Generally, though, can we guarantee that plugins will respect the various sandbox flags that are set? Assuming that we allow PNaCl iff 'allow-script' is set, could we prevent it from opening new windows unless the 'allow-popups' flag is set? Or from navigating the top-level context unless 'allow-top-navigation' is set, etc? There are a number of flags, and it's not clear to me which we'd be able to easily apply to PNaCl (or same-origin Flash, for that matter)?

-mike

--
Mike West <mk...@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Darin Fisher

unread,
Oct 8, 2014, 11:39:21 PM10/8/14
to Mike West, peppe...@chromium.org, ncb...@chromium.org, Thomas Sepez, Adam Barth, Nick Bray

There are no pepper APIs to open windows or navigate windows. NPAPI can do those things, but Pepper instead expects the programmer to delegate such things to JS in the embedding page.

Antoine Labour

unread,
Oct 9, 2014, 2:44:38 AM10/9/14
to Darin Fisher, Mike West, peppe...@chromium.org, ncb...@chromium.org, Thomas Sepez, Adam Barth, Nick Bray
On Wed, Oct 8, 2014 at 8:39 PM, Darin Fisher <da...@chromium.org> wrote:

There are no pepper APIs to open windows or navigate windows. NPAPI can do those things, but Pepper instead expects the programmer to delegate such things to JS in the embedding page.


FYI, Flash has a private API to do it (PPB_Flash.Navigate), but agreed it's not exposed to pNaCl.

Antoine
Reply all
Reply to author
Forward
0 new messages