This is a follow-up to bug 929172, that I file as a separate bug because we think it is security sensitive. I did some tests and had a lengthy discussion with Vivien. Let me explain how the test-agent works first: * we need a DEBUG=1 profile. In this profile, all apps are loaded from a http:// scheme, from a locally installed httpd.js extension that serves the apps. Each apps has its own hostname, but a pref maps these hostnames to localhost. * the test-agent is a normal installed app. It's not privileged nor certified, and merely has the "power" permission to ensure that the phone stays awake. The test-agent's origin is http://test-agent.gaiamobile.org:8080. * it loads tests inside an iframe, this iframe's src is the test's entry point, an html file hosted in the app's hostname, eg http://sms.gaiamobile.org:8080 And now, let me explain the context: * bug 927493 broke the test-agent on B2G Desktop (which is bug 929172) * the issue was that all tests are using files from the test-agent common hostname, and this was forbidden by the new fast path for certified apps. * I fixed the issue by ensuring these files were loaded from the same hostname that was serving the test's entry html page. Some tests are still failing for the exact same reason: they try to load files from another hostname (eg: communications/dialer (hostname is http://communications.gaiamobile.org:8080) tries to load a file from the SMS domain (http://sms.gaiamobile.org:8080)) and this is forbidden by the CSP for certified apps. So, what is strange here, is that since the test-agent is not certified (not even privileged), it should not have trigged the fast CSP path from bug 927493, becaue that path is used only for certified apps. Therefore, here is what I think happens: the _iframe_ from the test-agent is considered certified for the installed apps that use the same origin. I mean, if we use the html entry point for the SMS app, then the iframe content is considered certified, because the installed SMS app is certified. I think this is wrong: from a unprivileged app, using an iframe should never trigger certified content. Now, I don't know what is the real impact on production devices. Hosted apps can't be privileged nor certified on production devices. However, we can imagine installed hosted apps with some permissions, and another app using an iframe to gain those permissions through clickjacking. Needinfo Fabrice who can help finding the root cause, or just tell me I'm hallucinating. ;)

Julien, I quite don't follow your explanations, sorry... From what I saw in https://bugzilla.mozilla.org/show_bug.cgi?id=927493#c21 it seemed to me that: test-container (which is certified and has embed-apps permissions) was loading apps in a mozbrowser iframe, like the system app does. So it's no surprise that the iframed app is certified - we want that. And when it tries to load content from test-agent, we reject the load as expected. That being said, if you can reproduce the issue you suspect with a simple test case that would help a lot. I'm confused by the role of test-container and test-agent tbh.

The fact is: we don't use the test-container at all in unit tests. We're using _only_ the test-agent. AFAIK the test-container is used for mochitests only, but it's not concerned by this bug at all, so please move it out of your mind ;) I'll try to reproduce with simpler apps, but I lack time especially this week so maybe more next week.

Paul: what security rating should this get? having an iframe run with certified privs doesn't sound all that great but I'm not sure I'm understanding the context.

So firstly, test-agent is not certified, so doesn't get the power permission. I'm still digging into this.

So I can't reproduce the issue here, hopefully you hallucinating :) I did some testing on b2g desktop just to make sure. I embedded the gallery app inside the gaia template app, just to see what would happen, and also modified the gallery start page to log its current app status. When loaded normally the gallery logs "certified". When loaded inside the template app, navigator.mozApp.getSelf() doesn't return an app object since it is not an app domain. Im pretty sure that rules out any chance of the page actually being certified (I also observed that permissions are not granted to an certified app when embeded inside a regular app). Im not sure how 100% identify the status of an open window. I assume its something like look at the nodePrincipal on the contentDocument of the iframe. I tried to do this in Marionette & set_context('chrome'), but I couldn't get it to return me the principal. (Mostly because I am not exactly sure what I am doing).

BTW my understanding is that the 'app' that a content gets loaded inside is based on the mozapp attribute of an iframe, not the src attribute. mozApp is ignored unless the page doing the embedding has the 'embed-apps' permissions, and only the system app (and test-container apparently) has this. If an an loads an iframe inside itself that is same origin, then it will be considered as part of the app. If this iframe is navigated to a different origin, it will no longer be considered part of the app for security purposes. (e.g. calling navigator.mozApps.getSelf() will no longer succeed).

So, this looks good from a security point of view. Then I don't understand how we trigger the CSP check for a certified app :(

Have we tested to make sure certified apps do, in fact, get a CSP applied? If they do does that make this a non-security bug we can unhide?

Yes: http://mxr.mozilla.org/mozilla-central/source/content/base/test/csp/test_csp_bug768029.html We also test this as part of manual Gaia security testing.

Julien, can you provide me some steps to reproduce this issue and I'll do some digging?

From a gaia directory, here is how you can see the issue: * run "bin/gaia-test -d" => This will run the test-agent inside b2g desktop => this will run the test-agent server as well * run "touch apps/communications/dialer/test/unit/call_log_test.js" => this will make the test-agent execute the tests in this file, and fail because one of the files can't be loaded because of the CSP checks. In this case, it tries to load "http://sms.gaiamobile.org:8080/test/unit/mock_async_storage.js" from a frame that has the origin "http://communications.gaiamobile.org:8080", that is included by the test-agent. The test-agent itself is run using the "--runapp" argument to B2G, I don't know if this has any importance. Also, in case the tests themselves are fixed in the future, here is the Gaia hash that has the failing code: 9e451ffd1e10cdc024709e62a2a8252e82e0e435

Paul, can you dig in now that you have steps?

Note that in bug 993944 I'll fix the issue in call_log_test.js so as I said please stick to the Gaia hash that shows the issue.

I reproduced the bug following Julien's instructions. A quick remark for the record: 1. Running bin/gaiatest -d once, I get the failure. If I kill the app, and re-launch it, the test-agent fails at running properly 2. To fix that, I run run/gaiatest without any option. There all tests pass. Then run with the -d option again, and all tests pass too. 3. Deleting profile-debug/ and doing 1. reproduces the bug again, so I suspect some cache issues.

So I managed to reproduce but still digging. My guess is this is due to whatever setup is used for the tests. For example, you say that the test app has the power permission - this is a _certified_ permission, so in order to get this permission there must be something special going on. One note - while i did observe you error when running tests with the "bin/gaiatest -d", if you just open b2g-desktop, open the test-agent app and run the test in question, this passed for me, with no such error. Which further makes be think its something to do with test setup. I'll keep digging though.

The --runapp option seems to trigger something since the test fails when run after a b2g/b2g-bin -profile /home/stephouillon/dev/my-dev/gaia/profile-debug --runapp "Test Agent" but succeeds when --runapp is omitted. I've seen nothing bad in runapp.js though.

I think the main thing to do here is to decide/find out whether this can happen on a device, and what are the possible consequences.

What's the next step here?

I have no other next step than what I already said in comment 17 :) Not really my call.

(In reply to Al Billings [:abillings] from comment #18) > What's the next step here? The next step is to figure out what is the cause. I haven't been able to reliably reproduce this issue - I get similar symptons but haven't been able to conclusively say that this issue is related to app-status or CSP. My guess is it something to do with the debug builds or test configuration, and I haven't seen any evidence yet that this affects production builds. Further in production, privilged and certified apps have the app:// origin. It is forbidden to load or link to app: unless you have the webapps-manage permission, which is certified only. Long term to be sure, we could add a negative test to http://mxr.mozilla.org/mozilla-central/source/dom/permission/tests/test_embed-apps.html to avoid regressions in this area perhaps.

(In reply to Paul Theriault [:pauljt] from comment #20) > > The next step is to figure out what is the cause. I haven't been able to > reliably reproduce this issue - I get similar symptons but haven't been able > to conclusively say that this issue is related to app-status or CSP. Who is doing this figuring out?

I guess I am unless someone else does, but as I say, I don't have cause to think this affects production at the moment, so I probably wont be prioritizing this anytime soon (unless someone convinces me otherwise?) . From talking to Christoph Kerschbaumer, there are some CSP changes that are landing at the moment which may affect this, but really I am just guessing at the moment until we can reliably confirm this is a CSP issue.

DOM Apps are dead.