1373034 - Gather telemetry on whether Firefox is installed as root

Status: NEW

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

Description

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

Occasionally there are questions about supporting namespace/chroot sandboxing (discussed in bug 986397) with a setuid root helper executable, for Linux distributions that don't support (and may not ever support?) unprivileged user namespaces.  One of the problems here is that this works only with Firefox installed as root (usually from system packages), and we also support downloading and unpacking the tarball as a regular user.

So this raises some questions: How much of the Linux userbase is using packaged vs. downloaded Firefox, and how does that cross-tabulate with unprivileged user namespace support?

Telemetry could help.  There's going to be some selection bias, because telemetry isn't enabled by default and downstream builds might not (often don't?) enable it, but I expect that the non-root userbase is mostly Mozilla's builds (it would also include people doing their own builds and installing as non-root, but I think there's not so much of that), so underreporting would mostly be on the "is root" side.

So if the "no unprivileged userns, but is root" fraction as known to Telemetry turns out to be convincingly large, then the actual value is likely larger and the question is answered.  If it's not so large, then we're still in the realm of speculation.

Comment 1

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

Attachment: Data review request form

Patch to follow shortly.

Comment 2

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

Attachment: Bug 1373034 - Collect telemetry on whether the application is installed as root.

For the population where this probe is true but SANDBOX_HAS_USER_NAMESPACES is false,
sandbox security could be improved by allowing the use of a setuid root child process
wrapper, like the original Chromium Linux sandbox.

This is opt-out telemetry, because the prerelease channels aren't
representative of the larger population.

Also fixes some nearby indentation in Histograms.json.

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

Comment 3

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

Also this is specifically for desktop Linux; it's not meaningful on Android.  It's also not collected on Android, because `#ifdef MOZ_SANDBOX` is false there.  The not-Android-ness could be made explicit in the code, but I don't know how much sense it makes to try to “future-proof” like that — there aren't even concrete plans for GeckoView sandboxing at this point.

Comment 4

[Mike Hommey [:glandium]]

How many Firefox-installed-as-root are actually sending us telemetry? AIUI, telemetry is not sent without MOZ_TELEMETRY_REPORTING, and that's only set from our in-tree mozconfigs, which means it's very unlikely to be set in distro builds. And people who download Firefox builds from mozilla are very unlikely to be using it as root (which is a problem on its own, if you ask me). Figuring out the latter might be useful, but I'm not sure this is what you're actually after here.

Comment 5

[Chris H-C :chutten]

Comment on attachment 8979420 [details]
Bug 1373034 - Collect telemetry on whether the application is installed as root.

https://reviewboard.mozilla.org/r/245592/#review251850

One "author's choice", but otherwise the telemetry use is just peachy.

::: toolkit/components/telemetry/Histograms.json:12524
(Diff revision 1)
> +    "record_in_processes": ["main"],
> +    "alert_emails": ["[e-mail]", "[e-mail]"],
> +    "bug_numbers": [1373034],
> +    "expires_in_version": "65",
> +    "releaseChannelCollection": "opt-out",
> +    "kind": "boolean",

If this is only going to run once, perhaps consider a bool scalar? boolean histograms are designed to collect multiple true and false values. Both will get the job done, but scalars are easier to deal with in analysis.

Comment 6

[Chris H-C :chutten]

Comment on attachment 8979418 [details]
Data review request form

DATA COLLECTION REVIEW RESPONSE:

    Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Standard Telemetry mechanisms apply.

    Is there a control mechanism that allows the user to turn the data collection on and off?

Standard Telemetry mechanisms apply.

    If the request is for permanent data collection, is there someone who will monitor the data over time?

This collection isn't permanent.

    Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Type 1.

    Is the data collection request for default-on or default-off?

Default-on.

    Does the instrumentation include the addition of any new identifiers?

No.

    Is the data collection covered by the existing Firefox privacy notice?

No.

    Does there need to be a check-in in the future to determine whether to renew the data?

Yes. :jld, could you file a bug to evaluate this probe's usefulness towards before its expiry?

---
Result: datareview+

Comment 7

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

(In reply to Mike Hommey [:glandium] from comment #4)
> How many Firefox-installed-as-root are actually sending us telemetry? AIUI,
> telemetry is not sent without MOZ_TELEMETRY_REPORTING, and that's only set
> from our in-tree mozconfigs, which means it's very unlikely to be set in
> distro builds. And people who download Firefox builds from mozilla are very
> unlikely to be using it as root (which is a problem on its own, if you ask
> me). Figuring out the latter might be useful, but I'm not sure this is what
> you're actually after here.

Some distributions do opt in to telemetry, most prominently Ubuntu; see https://sql.telemetry.mozilla.org/queries/53970 for a list of approximately everyone who does that and also sets a partner distribution ID.

As for Mozilla builds being installed as root, I was thinking of distribution packages that repack our binaries, which exist (e.g., Arch seems to do this for at least ESR and Beta) but I don't know how prevalent they are.

But, now that I know about partner.distribution_id, I'm thinking that it might make sense to just use that instead of landing this probe: it will necessarily undercount distro packages because of the ones that don't enable telemetry, and it will also overcount “our” builds (by including “firefox-bin” type packages and maybe also unlabelled local builds), but those errors are in the same direction, and the goal here was just to get an approximate upper bound on the not-as-root population because that's the best I could do anyway.

Comment 8

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

Bug 1352981 and its dependencies also have some information on Linux Telemetry.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Moving to p3 because no activity for at least 24 weeks.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information