AIUI, when things are operating normally, the DOM code in content processes checks capabilities and never forwards requests to the parent that would fail the "backstop" check. Mounir/Jonas/Justin, is that correct? If so, then the only times a backstop stop check will fail is if there's a gecko bug or the process has been compromised. In either case it's safest to just terminate the misbehaving process. We should also ensure this is reported through a high-priority crash report, since it might be evidence of a security bug we need to fix.

> AIUI, when things are operating normally, the DOM code in content processes checks capabilities > and never forwards requests to the parent that would fail the "backstop" check. Mounir/Jonas > /Justin, is that correct? I'm not sure about is, but it should be correct, I think. And the reason is, the child process needs to do its own security checks, because there are times when a content process will run content with lower privilege than the maximum privilege available to the process, so if it's doing any security checks, it might as well do a full set of security checks.

Why should this block?

It's an essential part of bug 746280 -- we have to do /something/ when the child process misbehaves, and better to fail closed.

Chris, do you have someone in mind who could take this?

This is kind of a metabug... Or maybe it's more of a directive and shouldn't be a bug -- the work is to add these backstop checks, and then killing the content process is a pretty trivial consequence of adding the checks.

This is a very specific work item to kill content processes that fail an AppProcessHasCapability() check in their parent.

Comment on attachment 658402 [details] [diff] [review] Kill subprocesses that fail backstop permission checks I see why it's safe not to immediately kill the process when it fails the permission check, but it's not clear to me that the behavior in ProcessingError is safe (the old and new behavior is the same) -- we don't need to immediately stop listening to the child upon receiving a processing error? Anyway, this is certainly better than what we had, so r=me!