Comment 9 for bug 1770600

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