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 to expect breakage if
you opted in for Apparmor containment.
It's too bad that Firefox's snap (https://snapcraft.io/firefox) is
lagging behind otherwise we'd have Apparmor protection and more.
Regards,
Simon
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1770600
Title:
Firefox v60: does not work after update, many "DENIED" log entries
etc.
Status in firefox package in Ubuntu:
Confirmed
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1770600/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
