Linux content sandbox tightened

[Gian-Carlo Pascutto]

Hi all,

the next Nightly build will have a significantly tightened Linux
sandbox. Writes are no longer allowed except to shared memory (for IPC),
and to the system TMPDIR (and we're eventually going to get rid of the
latter, perhaps with an intermediate step to a Firefox-content-specific
tmpdir).

There might be some compatibility fallout from this. Extensions/add-ons
that try to write from the content process will no longer work, but the
impact there should be limited given that similar (and stricter)
restrictions have been tried out on macOS. (See bug 1187099 and bug
1288874 for info/discussion). Because Firefox currently still loads a
number of external libraries into the content process (glib, gtk,
pulseaudio, etc) there is some risk of breakage there as well. You know
where to report (Component: Security - Process Sandboxing).

This behavior can be controlled via a pref:
pref("security.sandbox.content.level", 2);

Reverting this to 1 goes back to the previous behavior where the set of
allowable system calls is restricted, but no filtering happens on
filesytem IO.

When Firefox is built with debugging enabled, it will log any policy
violations. Currently, a clean Nightly build will show some of those.
They are inconsequential, and we'll deal with them, eventually. (Patches
welcome though!)

--
GCP

[Jason Duell]

It sounds like this is going to break all file:// URI accesses until we
finish implementing e10s support for them:

https://bugzilla.mozilla.org/show_bug.cgi?id=922481

That may be more bustage on nightly than is acceptable?

Jason

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



--

Jason

[Jason Duell]

Never mind--file:// only does reads.

Haven't had my coffee yet this morning :)

Jason

On Fri, Oct 7, 2016 at 10:13 AM, Jason Duell <jdu...@mozilla.com> wrote:

> It sounds like this is going to break all file:// URI accesses until we
> finish implementing e10s support for them:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=922481
>
> That may be more bustage on nightly than is acceptable?
>
> Jason
>
>
> On Fri, Oct 7, 2016 at 9:49 AM, Gian-Carlo Pascutto <g...@mozilla.com>
> wrote:
>

>> _______________________________________________
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>

--

Jason

[Daniel Holbert]

On 10/07/2016 12:49 AM, Gian-Carlo Pascutto wrote:
> This behavior can be controlled via a pref:
> pref("security.sandbox.content.level", 2);
>
> Reverting this to 1 goes back to the previous behavior

Warning: don't actually try to revert this to 1, just yet -- at the
moment, that triggers startup crashes as described in
https://bugzilla.mozilla.org/show_bug.cgi?id=1308568

~Daniel

[Gian-Carlo Pascutto]

Fix for that is now on inbound, should be in tomorrow's Nightly.

It looks like the logging is also a bit more spammy for people than
expected, so there's patches ready for that too (bug 1308564). This
doesn't affect you unless you're debugging Firefox, though.

--
GCP

[Gerald Squelart]

Hi Gian-Carlo,

It seems this tightening is now preventing us from using ALSA:
https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c167

Coincidentally, we have just disabled ALSA by default, but the code is still there and can be enable in builds, so it'd be nice to allow its use for power-users who are still stuck with it, if that's possible.
I'll probably open a new bug about that soon. Is there some meta-bug we can block? (I couldn't find any.) Or just NI you?

Cheers,
Gerald

[Gian-Carlo Pascutto]

On 11-10-16 03:00, Gerald Squelart wrote:
> It seems this tightening is now preventing us from using ALSA:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1247056#c167
>
> Coincidentally, we have just disabled ALSA by default, but the code
> is still there and can be enable in builds, so it'd be nice to allow
> its use for power-users who are still stuck with it, if that's
> possible. I'll probably open a new bug about that soon. Is there some
> meta-bug we can block? (I couldn't find any.) Or just NI you?

For now you can block bug 1289718. I see you filed bug 1309098 for this
and I'll follow up there.

--
GCP