1370578 - Extend sandboxing telemetry probes for Linux features

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, enhancement)

Description

[Gian-Carlo Pascutto [:gcp]]

Looking at the sandboxing telemetry for Linux features, seccomp is now mostly universal, but tsync isn't (~90%), and User Namespaces are between 75-85%.

We probably want to extend the telemetry for the last 2. I'm not sure we care how much coverage tsync has?

Comment 1

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

It might still be worth gathering data on tsync, but I'm not sure.  The only design decision we'll need to make that involves tsync is whether to disable pid namespace support (bug 1151624) if there's no tsync or try to adapt the signal broadcast code to deal with it.  (procfs uses pids/tids from the namespace where it was mounted, not the namespace of the task accessing it.)  The benefit there is relatively minor and we could decide that we're already past the point were it'd be worth it, but more data wouldn't hurt.  Also, someday I'd like to remove all that code, but it's not really a maintenance problem (bug 1257361 notwithstanding) so there's no hurry.

User namespaces I'm more interested in, because it's possible that support won't ever converge on 100%.  The two classes of security bugs that discourage enabling it are corner cases in authorization, like [CVE-2014-8989][] or [CVE-2014-4014][], and exposure of kernel attack surface normally limited to root, like [CVE-2017-7308][].  I'm willing to believe that new bugs in the former class are unlikely to be added now that user namespaces are better understood and any existing bugs will eventually go extinct, but the latter can be added by essentially any change.

Also, the Telemetry Evolution Dashboard for unprivileged user namespaces shows it *decreasing* over the last two release cycles, especially in the e10s-capable subpopulation, so that's another reason we need to continue keeping an eye on it.

[CVE-2014-8989]: https://lwn.net/Articles/626665/
[CVE-2014-4014]: https://www.cvedetails.com/cve/CVE-2014-4014/
[CVE-2017-7308]: https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html

Comment 2

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

52 is when Arch enabled Telemetry, and the date of this change exactly matches a sudden large increase in the non-userns population (from ~5% to ~10%, then slowly increasing to ~13%): https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/firefox&id=0368ebdb85ec

Comment 3

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

Attachment: Bug 1370578 - Extend telemetry for support of some Linux sandbox features. data-r?bsmedberg

Basic seccomp-bpf support is not being renewed because it has already
passed 99% and is not expected to decrease, but seccomp thread
synchronization and (especially) user namespace support will continue to
be monitored.

Review commit: https://reviewboard.mozilla.org/r/150026/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/150026/

Comment 4

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

Comment on attachment 8878717 [details]
Bug 1370578 - Extend telemetry for support of some Linux sandbox features.  data-r?bsmedberg

MozReview doesn't understand “data-r?”; setting it myself.

Also, I notice that this isn't marked opt-out, which I'd assume would give us a small and probably unrepresentative subset of release users, but the sample counts on the telemetry.mozilla.org dashboard seem relatively high.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 8878717 [details]
Bug 1370578 - Extend telemetry for support of some Linux sandbox features.  data-r?bsmedberg

https://reviewboard.mozilla.org/r/150026/#review155132

::: toolkit/components/telemetry/Histograms.json:12511
(Diff revision 1)
>    },
>   "SANDBOX_MEDIA_ENABLED": {
>      "record_in_processes": ["main", "content"],
>      "alert_emails": ["[e-mail]"],
>      "bug_numbers": [1098428],
>      "expires_in_version": "55",

Do we care about this one?

::: toolkit/components/telemetry/Histograms.json:12520
(Diff revision 1)
>    },
>   "SANDBOX_CONTENT_ENABLED": {
>      "record_in_processes": ["main", "content"],
>      "alert_emails": ["[e-mail]"],
>      "bug_numbers": [1098428],
>      "expires_in_version": "55",

Same? It's a function of the others I guess, but seems good to have.

Comment 6

[Benjamin Smedberg]

Comment on attachment 8878717 [details]
Bug 1370578 - Extend telemetry for support of some Linux sandbox features.  data-r?bsmedberg

https://reviewboard.mozilla.org/r/150026/#review155280

data-r=me

Comment 7

[Benjamin Smedberg]

You're correct that currently this is opt-in, and you can't make much if any conclusion about the release population from this. That might matter for Linux in particular because of the distros!

Note that t.m.o only ever shows you the opt-in population, as a result of its design, so if you want to analyze the opt-out population you need to use custom queries or work with a data engineering partner.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/fba69ee2166a
Extend telemetry for support of some Linux sandbox features. r=gcp data-r=bsmedberg

Comment 9

[Carsten Book [:Tomcat]]

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