1403931 - [meta] Enable USER_RESTRICTED for content processes

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, enhancement, P2)

Description

[Jim Mathies [:jimm]]

USER_RESTRICTED
* breaks font loading
* removes networking
* breaks web audio /  webrtc?
* removes remaining read access (user token)
* TBD

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Note: removing the network access is also important in the context that it removes any excuse to inject into the content process to inspect networking.

Comment 2

[Christian Holler (:decoder)]

Hey Bob, do we have any timeline for shipping this? are there blockers or other concerns left that need to be addressed or can we start an experiment?

Comment 3

[Bob Owen (:bobowen) (PTO until 5th Oct)]

(In reply to Christian Holler (:decoder) from comment #2)

Hey Bob, do we have any timeline for shipping this? are there blockers or other concerns left that need to be addressed or can we start an experiment?

No blockers that I know of.
I've just started looking at the experiment documentation (for nimbus I think).
Not clear whether we need extra code or how much work setting up the experiment is, I've barely had any experience of it.

Comment 4

[Bob Owen (:bobowen) (PTO until 5th Oct)]

I've checked back through the list of things that disqualify win32k lockdown.

• Safe mode: We don't drop back to USER_LIMITED for this, it is a bit odd to have safe mode make security worse, but it probably makes sense initially. We should probably remove this check for win32k lockdown now.
• Env var: We already have an env var to disable the sandbox, I don't think we need one specifically for dropping back to USER_LIMITED.
• No e10s: As far as I can tell this can no longer be disabled in official builds when non-local connections are allowed and only then by env var. Obviously this is only a reason disabled reporting thing either way.
• Win10 Creators update or later: Not relevant for USER_RESTRICTED.
• Windows Exploit Protection mitigations: All the ones checked for in the win32k lockdown code don't seem to affect USER_RESTRICTED.
• Missing webgl oop: We have a check for this, but the win32k lockdown one includes a feature check ... we should probably add this.
• Missing remote decoders: We have a check for this.

Win32k lockdown also used to have check for missing webrender and non-native theme, but these were removed because it is not possible to disable either any more.

So, in summary our checks are probably fine, but adding safe mode and webgl oop feature check is probably a good idea.

Comment 5

[Bob Owen (:bobowen) (PTO until 5th Oct)]

For reference - experiment links:
Experiment Brief document
Nimbus experiment
Experiment QA Jira Ticket

Comment 6

[Dan [:dan23]]

(In reply to Bob Owen (:bobowen) from comment #5)

For reference - experiment links:
Experiment Brief document
Nimbus experiment
Experiment QA Jira Ticket
Note, only for Mozilla staff with special access (me not sadly)

Comment 7

[Bob Owen (:bobowen) (PTO until 5th Oct)]

Attachment: Bug 1403931: Enable USER_RESTRICTED on content process sandbox for Release. r=handyman!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0c0b8336537e
Enable USER_RESTRICTED on content process sandbox for Release. r=gcp

Comment 9

[amarc]

https://hg.mozilla.org/mozilla-central/rev/0c0b8336537e