Re: Linux content sandbox tightened
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Linux content sandbox tightened
On Friday, October 7, 2016 at 6:49:53 PM UTC+11, Gian-Carlo Pascutto wrote:
> 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
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Linux content sandbox tightened
On 07-10-16 20:47, Daniel Holbert wrote:
> 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
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Linux content sandbox tightened
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Linux content sandbox tightened
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 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
> wrote:
>
>> 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
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>
--
Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Linux content sandbox tightened
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 wrote:
> 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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
