1965103 - Convert `security.sandbox.content.headless` into Linux content sandbox level 5

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, task)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This is inspired by bug 1302711: ioctl lockdown ought to be a new sandbox level on top of the existing ones, but it basically depends on security.sandbox.content.headless (blocking ioctls will break in-process use of graphics drivers). It would make sense to turn ….content.headless (which one could think of as “graphics lockdown”, perhaps) into sandbox level 5, retroactively, and add ioctl lockdown as level 6.

ProfileDataUpgrader could be used handle the case of profiles with ….content.headless turned off; that isn't really a supported configuration (it shouldn't be done unless the only alternative is turning off sandboxing entirely), but it wouldn't be too hard to avoid breaking it.

The one awkward thing is that ….content.headless both tightens the sandbox policy and changes the graphics stack configuration by setting MOZ_HEADLESS in content processes, and it might be a little weird from the perspective of graphics if the situation became “headless mode is used unless this non-graphics int pref has value ≤ 4”. So, that might need some rethinking — maybe headless content could be used automatically iff out-of-process WebGL is enabled, or something along those lines.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: Bug 1965103 - Turn `security.sandbox.content.headless` into sandbox level 5. r?gcp!

Comment 2

[Tom Schuster (MoCo)]

I think there might actually be some upsides to not trying to upgrade security.sandbox.content.headless by forcing users on a less secure sandboxing level. We don't really know why people set this, but it's quite possible that whatever reason they had doesn't apply anymore and we shouldn't keep them in a less secure state. Worst case they can just reduce the sandbox level once again.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Tom Schuster (MoCo) from comment #2)

I think there might actually be some upsides to not trying to upgrade security.sandbox.content.headless by forcing users on a less secure sandboxing level. We don't really know why people set this, but it's quite possible that whatever reason they had doesn't apply anymore and we shouldn't keep them in a less secure state. Worst case they can just reduce the sandbox level once again.

Honestly, I was thinking the same thing (especially after seeing the minimum sandbox level code for Windows and thinking about what we might want to do there on Linux). I'll probably drop that part of the patch unless someone has a convincing argument for it (but it's nice to know that we can do that if needed).

The one thing I know of in Firefox that would conflict with headless content is turning off webgl.out-of-process, but we stopped testing or supporting that configuration a while ago IIRC, and that's also a case where early bugs might well have been fixed by now (or, if not, should be filed). So I think the advice is: if things break and webgl.out-of-process was flipped, then try resetting it; otherwise or if that doesn't work, file a bug (and lower sandbox level to 4 as a workaround, but please try not to do that).

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fc78ea3c0414
Turn `security.sandbox.content.headless` into sandbox level 5. r=firefox-desktop-core-reviewers ,mossop,gcp

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/fc78ea3c0414