Firefox v60: does not work after update, many "DENIED" log entries etc.

[daniel CURTIS]

Hello.

Today, Firefox has been updated to v60. After first start there was so many problems: with new tab (errors), Sandbox option (one new option with 'false' value). There were so many issues. No website was working, I can not click on anything, there was no menu bar and so on. Firefox main windows has been resized etc.

Anyway, there was also a lot of "DENIED" entries in a log files. Here are the AppArmor rules, that helped and now Firefox works okay. Maybe it will help someone too?

# apparmor="DENIED" operation="capable"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}" comm="firefox"capability=21
# capname="sys_admin"
#
capability sys_admin,

# apparmor="DENIED" operation="capable"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}" comm="firefox"
# capability=19 capname="sys_ptrace"
#
capability sys_ptrace,

# apparmor="DENIED" operation="capable"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}" comm="Gecko_IOThread"
# capability=18 capname="sys_chroot"
#
capability sys_chroot,

# NOTE: what about an "owner" prefix?
#
# apparmor="DENIED" operation="open"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/proc/4137/uid_map"
# comm="Gecko_IOThread" requested_mask="w" denied_mask="w"
# fsuid=1000 ouid=1000
#
@{PROC}/@{pid}/uid_map w,

# NOTE: what about an "owner" prefix?
#
# apparmor="DENIED" operation="open"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/proc/4282/gid_map"
# comm="Gecko_IOThread" requested_mask="w" denied_mask="w"
# fsuid=1000 ouid=1000
#
@{PROC}/@{pid}/gid_map w,

# NOTE: what about an "owner" prefix?
#
# apparmor="DENIED" operation="open"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/pro /4282/setgroups"
# comm="Gecko_IOThread" requested_mask="w" denied_mask="w"
# fsuid=1000 ouid=1000
#
@{PROC}/@{pid}/setgroups w,

# NOTE: what about an "owner" prefix?
#
# apparmor="DENIED" operation="dbus_bind" bus="session"
# name="org.mozilla.firefox.WAJxENJayq__" mask="bind"
# label="/usr/lib/firefox/firefox{,*[^s][^h]}"
#
dbus bind bus=session name=org.mozilla.firefox.*,

# NOTE: this rule can be found, for example, in "abstractions/X" file.
# However, there is "r" in 'requested{,denied}_mask" - for '/tmp/.X11-unix/'
# - in log entries, so I added "r" - and now it's "rw".
#
# apparmor="DENIED" operation="connect"
# profile="/usr/lib/firefox/firefox{,*[^s][^h]}"
# name="/tmp/.X11-unix/X0" comm="firefox" requested_mask="r" denied_mask="r"
# fsuid=1000 ouid=0
#
/tmp/.X11-unix/* rw,
unix (connect, receive, send)
      type=stream
      peer=(addr="@/tmp/.X11-unix/X[0-9]*"),

Can someone check if these rules are okay? With above rules, Firefox v60 is working okay again: web browsing, new tabs etc. There are also some "segfaults" error in log files - together with "DENIED" rules. Here are some of them (there is a bug report on Launchpad about "libxul"):

✗ [ 3051.788218] Gecko_IOThread[4770]: segfault at 0 ip aef1b0de sp aeb1a550 error 6 in libxul.so[aebed000+66fd000]
✗ Gecko_IOThread[4795]: segfault at 0 ip aef1b0de sp aeb1a550 error 6 in libxul.so[aebed000+66fd000]

I hope, that above rules will help other users who will have an issues with a new Firefox release. Here are some technical informations:

● Firefox: v60.0 (32-bit)
● Linux kernel: 4.4.0-125-generic
● Release: 16.04 LTS

Thanks, best regards.

[daniel CURTIS (anoda)]

I apologize for so much "description:updated", but I had some problems with text formatting etc. If these "posts" can be removed, please do it.

Thanks.

[daniel CURTIS (anoda)]

Hello.

I apologize, once again, for such a bad bug report, but I'm in a hurry (I just want to help, because there could be some issues with a new Firefox version - problems, that could appear after update. Just like in my case etc.) Anyway, there is a one entry in log files that makes me confused, because there is not so many informations that could help create a proper rule. Here is the log entry (appeared about 4, 5 times):

✗ apparmor="DENIED" operation="connect" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/tmp/.X11-unix/X0" pid=4643 comm="firefox" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

As I already mentioned, "abstractions/X" file contains rule related with "/tmp/.X11-unix/X0" and "connect" operation. However, there is also "type" and "peer" options (see report; last rule) - which is not in the log entry! So, it seems, that such rule is wrong... but Firefox started to work normally.

Anyway, I would like to ask if there can/should be used something like this - instead of a rule in bug report:

# Explicitly allow 'connect' unix permission
unix (connect),

(NOTE: chromium-browser profile also contains a few "unix" - but not with 'connect' option - and "capability" rules) What do you think? Which one solution is better:

- use the last rule mentioned in bug report (please note, that there is "rw" access for "/tmp/.X11-unix/X0" socket because of 'requested{,denied}_mask');
- allow only 'connect' unix permission (see this post);

Or maybe it should be only something like this? But that is just an idea. Crazy idea:

/tmp/.X11-unix/X[0-9]* r,

Thanks. I'm sorry once again.

[Simon Déziel (sdeziel)]

@Daniel, it looks like there was some changes to the sandboxing of Firefox. I needed to add the following rules to make FF 60 work again:

  # new with FF 60
  capability sys_admin,
  capability sys_chroot,
  capability sys_ptrace,
  owner @{PROC}/@{pid}/{u,g}id_map w,
  owner @{PROC}/@{pid}/setgroups w,

Similar to yours except that "owner" works for the files under /proc. Before adding all those rules, I got many crashes in libxul.so and libmozsandbox.so.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Simon Déziel (sdeziel)]

The sandboxing improvements are explained in more details here: https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html

Since I see no setuid binaries, presumably the additional capabilities are used in the unprivileged user namespace.

[Lonnie Lee Best (launchpad-startport)]

When will version 60 be released into Ubuntu 16.04.4?

[Simon Déziel (sdeziel)]

@Lonnie, it is already released, see the security announcement: https://usn.ubuntu.com/3645-1/

[daniel CURTIS (anoda)]

Hello Simon.

Thank You very much for an informations. Yes, there was some changes to the Sandbox (vide 'about:support'), because after update there was one new option with 'false' value (I have had similar issue in the past but it's not important now) and levels for the "Content Separation" and "Effective Content Separation" has changed to "4" (while in Firefox 59.0 version it was "3") etc.

I will also add an "owner" prefix to the '@{PROC}' rules. Thanks for clarifications; I waited for something like this, because I had no idea if "owner" should be used in such situation.

Anyway, if it's about the last rule in my report and this one mentioned in my comment #2: it seems, that when everything is commented, there is a problem with opening new tab (e.g. by clicking "+") - after ~2 hours of Firefox using there is an error message that "this tab has failed", "We can help!" etc. Everything else is working okay.

For now I decided to comment this rule, because I think it's a wrong rule (see my post #2 for more informations). As I already mentioned, "abstractions/X" file contains rule related with "/tmp/.X11-unix/X0" and "connect" operation. However, there is also "type" and "peer" options (see report; last rule) - which is not in the log entry! So, here is what I've done for now:

# Here are a rules from an "abstractions/X" file. However I used "rw" access. Reason:
# "r" access added because of log entries with 'requested{,denied}_mask=r' (see bug report)
#
/tmp/.X11-unix/* rw,

#unix (connect, receive, send)
# type=stream
# peer=(addr="@/tmp/.X11-unix/X[0-9]*"),

And everything seems to work okay: just as before update to 60.0 version. Okay, so for now I will:

✗ add an "owner" prefix for all '@{PROC}' rules (thanks Simon!);
✗ use only "/tmp/.X11-unix/* rw," rule (until more information will be gathered);
✗ monitor the log files, journalctl(1) command etc.

Once again: thank You Simon for an informations! I hope also that someone else will confirm the correctness of all these rules. (Especially these mentioned in bug report).

By the way: Simon, what about two rules: mentioned above "unix" and "dbus" rule (see bug report and 7. rule) Have you seen such an entries in your log files etc.? Did you have had a similar issues with firefox, just before adding rules (see bug report)?

Thanks, best regards.

[Simon Déziel (sdeziel)]

Hi Daniel,

On 2018-05-11 04:46 PM, daniel CURTIS wrote:
> Thank You very much for an informations. Yes, there was some changes to
> the Sandbox (vide 'about:support'), because after update there was one
> new option with 'false' value (I have had similar issue in the past but
> it's not important now) and levels for the "Content Separation" and
> "Effective Content Separation" has changed to "4" (while in Firefox 59.0
> version it was "3") etc.
>
> I will also add an "owner" prefix to the '@{PROC}' rules. Thanks for
> clarifications; I waited for something like this, because I had no idea
> if "owner" should be used in such situation.

When the denial message have "fsuid" equal to "ouid" it's a good hint to
try the "owner" prefix. fsuid is the UID of the file system object
accessed by the "ouid" which corresponds to the UID of the runnig
process trying to make the access. Those denials all had "fsuid=1000
ouid=1000".

> Anyway, if it's about the last rule in my report and this one mentioned
> in my comment #2: it seems, that when everything is commented, there is
> a problem with opening new tab (e.g. by clicking "+") - after ~2 hours
> of Firefox using there is an error message that "this tab has failed",
> "We can help!" etc. Everything else is working okay.
>
> For now I decided to comment this rule, because I think it's a wrong
> rule (see my post #2 for more informations). As I already mentioned,
> "abstractions/X" file contains rule related with "/tmp/.X11-unix/X0" and
> "connect" operation. However, there is also "type" and "peer" options
> (see report; last rule) - which is not in the log entry! So, here is
> what I've done for now:
>
> # Here are a rules from an "abstractions/X" file. However I used "rw" access. Reason:
> # "r" access added because of log entries with 'requested{,denied}_mask=r' (see bug report)
> #
> /tmp/.X11-unix/* rw,

Looking at etckeeper logs, "r" was added to abstractions/X on December
21st 2016. It was apparently a local/manual fix I made on that date.

> #unix (connect, receive, send)
> # type=stream
> # peer=(addr="@/tmp/.X11-unix/X[0-9]*"),
>
> And everything seems to work okay: just as before update to 60.0
> version. Okay, so for now I will:
>
> ✗ add an "owner" prefix for all '@{PROC}' rules (thanks Simon!);
> ✗ use only "/tmp/.X11-unix/* rw," rule (until more information will be gathered);
> ✗ monitor the log files, journalctl(1) command etc.
>
> Once again: thank You Simon for an informations! I hope also that
> someone else will confirm the correctness of all these rules.
> (Especially these mentioned in bug report).
>
> By the way: Simon, what about two rules: mentioned above "unix" and
> "dbus" rule (see bug report and 7. rule) Have you seen such an entries
> in your log files etc.? Did you have had a similar issues with firefox,
> just before adding rules (see bug report)?

I must admit I've been too lazy to do proper upstreaming of my local
Apparmor delta for firefox. I run with the following
local/usr.bin.firefox profile: https://paste.ubuntu.com/p/z5KFTQCkWC/

Since the FF profile is disabled by default, Ubuntu/Canonical folk do
not test it when releasing FF updates so you have...