Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers
On Fri, Sep 29, 2017 at 11:33:08PM -0400, Boris Zbarsky wrote:
On 9/29/17 3:32 PM, Kris Maglione wrote:
For instance, the following should all capture the caller principal
for the `src` URL at call time:
document.write(`http://example.com/favicon.ico";>`);
div.innerHTML = `http://example.com/favicon.ico";>`;
img.setAttribute("src", "http://example.com/favicon.ico";);
img.src = "http://example.com/favicon.ico";;
What is the plan to do this, concretely? Changing img.src to thread
through a principal is not too bad but doing it for setAttribute would
be a bit of a performance annoyance, and threading them through the
parser would be _quite_ annoying.
The other option is to basically use something like
SubjectPrincipal(), but we're trying to remove existing uses of that,
because the action-at-a-distance makes it hard to reason about its
security properties.
I still haven't settled on the details, but I it will probably
have to involve capturing the caller principal from SetAttr
hooks. Which would involve either changing that machinery to
pass along a JS context when invoked by a scripted caller, or
using something like SubjectPrincipal(). I'd definitely like to
hear opinions on the best approach here.
The question of how to handler parser-generated nodes is
tougher. Just using SubjectPrincipal() is one obvious approach,
but the security characteristics of that worry me (what if the
parser gets invoked by system code while some JS caller is
blocked?). So I think it will probably require some sort of
special activation records that we can check (and sanity check)
from the attribute hooks. But I've barely begun looking into
this part yet.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers
On 9/29/17 3:32 PM, Kris Maglione wrote:
For instance, the following should all capture the
caller principal for the `src` URL at call time:
document.write(`http://example.com/favicon.ico";>`);
div.innerHTML = `http://example.com/favicon.ico";>`;
img.setAttribute("src", "http://example.com/favicon.ico";);
img.src = "http://example.com/favicon.ico";;
What is the plan to do this, concretely? Changing img.src to thread
through a principal is not too bad but doing it for setAttribute would
be a bit of a performance annoyance, and threading them through the
parser would be _quite_ annoying.
The other option is to basically use something like SubjectPrincipal(),
but we're trying to remove existing uses of that, because the
action-at-a-distance makes it hard to reason about its security properties.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: CSP exemptions for content injected by privileged callers
Summary:
All content injected into web content pages is currently subject to the
same Content Security Policy, regardless of who injected it. For
privileged callers, such as extension content scripts, this means that
some functionality can behave erratically, depending on the page they're
running on.
The plan here is to apply a separate CSP to content injected by certain
privileged callers, rather than subjecting it to page CSP. Content from
system URLs (like moz-extension:) is already immune to CSP. This change
will extend that immunity to any content injected by those callers.
Implementation plan:
Implementing this will require that we record the caller principal
whenever content that loads a URL is injected into a page, and use that
principal as the triggering principal for the load.
My plan is to add a special attribute to principals, specifying that
their CSP should override the CSP of document principals that they
subsume. Initially, this flag would only apply to expanded principals
used in extension content scripts.
The exact mechanics of capturing the triggering principal will need to
vary, but in general, it should happen any time a particular source
attribute is set. For instance, the following should all capture the
caller principal for the `src` URL at call time:
document.write(`http://example.com/favicon.ico";>`);
div.innerHTML = `http://example.com/favicon.ico";>`;
img.setAttribute("src", "http://example.com/favicon.ico";);
img.src = "http://example.com/favicon.ico";;
Other alterations to the node should retain the existing principals for
existing attributes. For example:
img.setAttribute("src", "http://example.com/favicon.ico";);
window.wrappedJSObject.img = img;
window.wrappedJSObject.eval("document.body.appendChild(img)");
should retain the principal from the original setAttribute call, even
though the last insertion happens with a content caller principal.
Scripts injected in this way will not gain any special immunity to CSP.
For instance, this call will succeed regardless of site CSP:
document.createElement("script");
script.setAttribute("src", "https://cdn.framework.org/framework.js";);
document.head.appendElement(script);
but any attempts by that script to inject content that violates CSP will
fail, as will any attempts to inject content via that framework
(e.g., `window.wrappedJSObject.$("head").append("
Re: Rationalising Linux audio backend support
As someone who has had wonderful times with ALSA & headaches with PA it's time to say goodbye FireFox. FireFox was my first goto browser for years now I'll add it to my purge script just under pulseaudio. Expecting users to give up 2 hours & 15Gb just to get alsa support in a browser is tbf pointless, enjoy your reduced size market share. Farewell Dev's and thanks for all the code of yours I put to great use over the years. Bye, Tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Follow up on clang-format
Now instead we will get to try to phrase code in a way that clang-format will preserve readably? I should think "it doesn't always produce nice formatting, but it's at least consistent" sounds like a major warning sign, particularly given that we definitely have tricky code for which we have made efforts to maximize readability and maintainability. Maybe this is more useful for our more poorly manicured modules, but that it will drag down well-maintained code in favor of a lowest-common-denominator style is absolutely concerning to me. On Thu, Sep 28, 2017 at 1:15 AM, Chris Pearce wrote: > On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote: >> Some of you may remember the discussion on clang-format and the `mach >> clang-format` command. What we have in place right now is very temporary >> but it is functional enough to give it a try. I have not put the effort >> into upstreaming my changes. Depending on the feedback I receive I will >> either: >> >> * Finish my existing changes and upstream them >> * Remove the `mach clang-format` command altogether >> * Do nothing >> >> I have personally found it useful. However I would like to hear from >> other people who have tried it to help me decide what to do next. >> >> Anthony > > I use `./mach clang-format` on basically every patch I write. It has > eliminated the style nits that get picked up when people review my patches, > at least when I remember to run it! > > I've considered writing a commit hook to run `./mach clang-format` before > every commit, but haven't gotten around to it... > > `mach clang-format` is awesome, please don't remove it. > > As others have pointed out, it doesn't always produce nice formatting, but > it's at least consistent, and enforces the major style guide recommendations. > > It's also liberating not having to waste brain power deciding how to format > code. > > > cpearce. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Follow up on clang-format
Le 28/09/2017 à 23:21, Randell Jesup a écrit : >> On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote: >> Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact >> to clang-format the entire tree after 57. Sweet as! > Where did you find that? Was this plan communicated? It's not in this > thread... (which started with smaug replying to a 2014 post by Anthony). > Personally, this will mostly make me sad/annoyed and make figuring out > why code was landed a pain (can be a real pain for people who do a lot > of reviews), but I'll deal with it. I'm more concerned that this wasn't > communicated (or discussed!) well, since 58 is already open... > This is my fault, sorry about that. We have been working on that for a while with Ehsan, Andi and others. We delayed everything with the 57 work and are planning to start the discussions soon (I quickly mentioned that to Chris yesterday during an informal talk). More soon! Sylvestre ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
