Firefox apparmor profile: /usr/bin/python3: error while loading shared libraries: cannot apply additional memory protection after relocation: Permission denied

The following patch mitigates the error message, but it's only a partial fix for the issue (which is white tabs). Note that I had python 3.5 installed whereas the apparmor profile only supported 3.0-3.4.

So there's something else to do, and it also seems to be related to apparmor (because when disabling the profile tabs are rendered correctly).

In addition, I applied the suggestion from https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1495248.

Now the apparmor profile works:
- console output remains silent
- nothing is logged to /var/log/syslog
- firefox renders content again in tabs

My test was wrong (had another instance open with profile disabled)

The patch still does not fix the problem with white/black tabs, not rendering any content.

In syslog, I get:

Jan 28 02:13:58 lat61 dbus[3005]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/gtk/vfs/mounttracker" interface="org.gtk.vfs.MountTracker" member="ListMountableInfo" mask="send" name=":1.8" pid=19943 label="/usr/lib/firefox/firefox{,*[^s][^h]}" peer_pid=3101 peer_label="unconfined"
Jan 28 02:13:58 lat61 kernel: [10694.093307] audit: type=1400 audit(1485566038.221:44093): apparmor="DENIED" operation="open" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/proc/19943/net/arp" pid=19952 comm=4C696E6B204D6F6E69746F72 requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 28 02:13:59 lat61 dbus[3005]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/gtk/vfs/mounttracker" interface="org.gtk.vfs.MountTracker" member="ListMountableInfo" mask="send" name=":1.8" pid=19985 label="/usr/lib/firefox/firefox{,*[^s][^h]}" peer_pid=3101 peer_label="unconfined"
Jan 28 02:14:32 lat61 dbus[3005]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/gtk/vfs/mounttracker" interface="org.gtk.vfs.MountTracker" member="ListMountableInfo" mask="send" name=":1.8" pid=20044 label="/usr/lib/firefox/firefox{,*[^s][^h]}" peer_pid=3101 peer_label="unconfined"
Jan 28 02:14:33 lat61 kernel: [10729.374780] audit: type=1400 audit(1485566073.502:44094): apparmor="DENIED" operation="mknod" profile="/usr/lib/firefox/firefox{,*[^s][^h]}" name="/dev/shm/org.chromium.35D9xE" pid=20044 comm=57656220436F6E74656E74 requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

I fixed all the issues now.

Now the apparmor profile works:
- console output remains silent
- nothing is logged to /var/log/syslog
- firefox renders content again in tabs

Tested with ubuntu 16.04 (up-to-date) and firefox 51.0.1

Please reread the patch carefully in terms of security. I think I did not open it up too much, but in principle I just tried to get my firefox working again. Basically, I opened up everything apparmor was complaining about.

The attachment "usr.bin.firefox.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

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

Thanks, will take a look at that after the weekend

@chrisccoulson

Thanks. Please note that my patch is supposed to fix issues

- 1659922 apparmor blocking /dev/shm/org.chromium.[...]
- 1659988 apparmor blocking python 3.5
- 1495248 apparmor blocking blocks /dev/shm
- 1553712 apparmor blocking org.gtk.vfs.MountTracker
- 1628956 apparmor blocking /proc/[...]/net/arp
- 1643200 firefox showing black/white tabs (side effect of the fixes above)

I'm wondering why this has not been fixed earlier for a package like firefox. Bugs were reported a long time ago whereas each of the fixes was easy, and sometimes even suggested by the reporters.

Not only that: Every time a new major release of FF is released it seems to be necessary to also test and adapt the apparmor profile. In the future, that can and should be done _before_ releasing a firefox package.

I think this issue is not exactly a duplicate of bug #1659922.

The patch also fixes

- 1660086 apparmor blocking /usr/share/distro-info/debian.csv

Related or duplicate:

https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1627239

I'm optimistic that my patch fixes that as well.

Patch VERSION 4.

Here's a new version of the patch which also fixes:

- 1660272 Apparmor blocking Freedesktop interfaces on video playback
- 1660268 Apparmor blocking access to /sys/devices/system/node/node0/meminfo

It also backports a dev/ to run/ conversion needed for ubuntu 14.04 (and maybe 12.04, whereas I'm not sure for 12.04 yet).

It also fixes a syntax issue.

If you test this patch, please refer to it as "VERSION 4" of the patch.

Patch VERSION 5.

Here's a new version of the patch which also fixes:

- 1660287 Apparmor blocking FF to access org.gtk.vfs.Daemon and Mount

Patch VERSION 6.

Supposed to fix issues
- 1660287 apparmor blocking VFS related operations
- 1660314 apparmor blocking recently added files

regression potential: FF now exposes some other issues like:

https://bugs.launchpad.net/bugs/1660298 - which seems not to be apparmor related.

So far, I can't see something negative from a user perspective, however.

Just my 2 cents: we had the same problem here after the Firefox 51.0.1 update (just one machine is affected anyway, the others updated with no problem). The error message is NOT related to python, but I get graphics errors like the ones seen in bug #1643200:
[GFX1]: Failed 2 buffer db=0 dw=0 for 0, 0, 1920, 876
[GFX1]: Failed 2 buffer db=0 dw=0 for 0, 0, 1920, 876
[GFX1]: Failed 2 buffer db=0 dw=0 for 0, 0, 1920, 876
Anyway, excluding Firefox from Apparmor (as with the OP's first suggestion) works around the problem. My suspect is bad interaction with the driver for the videocard of that specific machine on which we have the problem.

@roberto-colnaghi I had similar issues as well. These have all gone in my case after applying my patch.

I'll post a comment in bug #1643200, eventually some of the affected users can test it.

@roberto-colnaghi Ah, my error. Thought this was a new issue.

It even gets better: The person who posted these

[GFX1]: Failed 2 buffer db=0 dw=0 for 0, 0, 1920, 876

errors was me.

And from my side, I can say that these issues all have gone (already with early versions of the patch).

@roberto-colnaghi Please try out VERSION 6 of the patch. I think it fixes the [GFX1] issues, too.

@thomas303 I can't apply the patch, it's a production machine. Besides, I don't understand which file has to be patched (I figured it was /usr/bin/firefox, but it doesn't contain any of the words found in the patch). Thanks anyway, I just wanted to highlight the fact that Python is probably not the cause, but ratherconflicts with problem drivers.

@roberto-colnaghi Not exactly. The patch is against the apparmor profile of FF only.

Attached, I send the full version of a patched apparmor profile (patched with VERSION 6)

You can even leave the existing profile untouched by disabling it with a separate link and adding a separate file as a root user:

#disable existing profile
cd /etc/apparmor.d/disable
ln -s ./../usr.bin.firefox
#adding patched version (attached to this comment)
cp /path/to/downloaded/usr.bin.firefox_patched /etc/apparmor.d/usr.bin.firefox_patched
#reload profiles
service apparmor reload

Now that the original profile file remains unchanged, apt-get won't complain when the official package gets updated.

As soon as the official package gets updated, there's nothing more to do than to do a
#enable profile from official package again
rm /etc/apparmor.d/disable/usr.bin.firefox
#remove patched version
rm /etc/apparmor.d/usr.bin.firefox_patched
#reload profiles
service apparmor reload

Bonus: That should be undoable even for a production system even if something breaks (whereas I assume that your production system currently is broken anyways).

Please report back if it fixes your issues. And which of them it fixes (in the corresponding bug IDs).

@roberto-colnaghi Indeed, python 3.5 dependency is not the cause for white/black tabs. But the patch fixes that, too. It fixes every apparmor blocking I'm aware of in terms of firefox.

@thomas303 Thank you very much! The system was not broken, because I disabled apparmor for Firefox as you said in the opening post (altough you intended it just for testing). Anyway, your instructions were very complete, and my doubt was mainly compatibility with Ubuntu update. But as you said, "Now that the original profile file remains unchanged, apt-get won't complain when the official package gets updated.", so it's fine for me. And it works like a charm, by the way!

@roberto-colnaghi Thanks for reporting back.

I thought you were affected by the black/white tabs, too. If not, Firefox should be usable at least (and indeed not be broken).

Which problem exactly did the patch fix for you? The [GFX1] stuff? Which version of FF/ubuntu did you test against?

Sorry, probably I wasn't clear enough: as I said, the problem (white rendering of web pages) showed up after the update to Firefox 51.0.1
Excluding it from Apparmor, Firefox became usable. Then, applying your patch, I was able to reenable Apparmor for Firefox and still displaying web pages correctly.

Thomas,

I believe I was already on FF 51.0.1, but after my Session Manager addon updated to 0.8.1.13, I began having the issue where everything from the Internet would display as black and white rectangles. I believe this happened immediately, but I can't be sure as I was chasing a separate problem at the time with gmail servers that appears to be a DNS issue (very long traceroute times).

I applied the patch as you described for usr.bin.firefox_patched in post #21, and FF began working again. Thanks for the work you put into the patch!

Reporting the patch is a fix for this bug (1659988) as well as 1643200, which is the first place I landed in LaunchPad.

Using:
Trusty
System76 gazp9 laptop
FF 51.0.1
Session Manager 0.8.1.13

@Thomas Mayer (thomas303)
Using your profile in #21, also, I take FF in enforce mode but partly always fall back to unconfined mode while the apparmor_status shows the complete FF in enforced mode. The download and upload only to and from a special folder does not work.

Part of kern.log:
Jan 31 21:10:17 tom kernel: [127276.261000] audit: type=1400 audit(1485893417.670:57134): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}" pid=27913 comm="apparmor_parser"
Jan 31 21:10:17 tom kernel: [127276.276889] audit: type=1400 audit(1485893417.686:57135): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//browser_java" pid=27913 comm="apparmor_parser"
Jan 31 21:10:17 tom kernel: [127276.276914] audit: type=1400 audit(1485893417.686:57136): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//browser_openjdk" pid=27913 comm="apparmor_parser"
Jan 31 21:10:17 tom kernel: [127276.276925] audit: type=1400 audit(1485893417.686:57137): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//lsb_release" pid=27913 comm="apparmor_parser"
Jan 31 21:10:17 tom kernel: [127276.276936] audit: type=1400 audit(1485893417.686:57138): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//sanitized_helper" pid=27913 comm="apparmor_parser"
Jan 31 21:10:24 tom kernel: [127282.852615] audit: type=1400 audit(1485893424.262:57139): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}" pid=27918 comm="apparmor_parser"
Jan 31 21:10:24 tom kernel: [127282.876766] audit: type=1400 audit(1485893424.286:57140): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//browser_java" pid=27918 comm="apparmor_parser"
Jan 31 21:10:24 tom kernel: [127282.877369] audit: type=1400 audit(1485893424.286:57141): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//browser_openjdk" pid=27918 comm="apparmor_parser"
Jan 31 21:10:24 tom kernel: [127282.877675] audit: type=1400 audit(1485893424.286:57142): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//lsb_release" pid=27918 comm="apparmor_parser"
Jan 31 21:10:24 tom kernel: [127282.877960] audit: type=1400 audit(1485893424.286:57143): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/firefox/firefox{,*[^s][^h]}//sanitized_helper" pid=27918 comm="apparmor_parser"

@sziraki.tamas I experienced myself that reading from / writing to files does not always work, depending on the chosen path. Is that your problem?

To some extent, I think this is intentional: If firefox could read/write to any path/file you have permissions as a user, that would render most of the apparmor blockings useless.

The patch (hopefully) does not touch this behaviour.

Suggestions welcome, but please file a new ticket for a new problem.

@blantonradford Thanks for reporting back.

Please report back in bug #1643200, which is the right place for black/white tabs.

I assume that your old version of Session Manager was incompatible to E10S, which is why firefox did not enable it, which is why it worked.

If Session Manager 0.8.1.13 fixed that incompatibility, E10S eventually got enabled because of that. Just with the result that you were left with black/white tabs, now that apparmor was blocking the new feature.

Patch VERSION 7

Also covers bug #1553763 (org.gtk.vfs.Metadata was still missing).

full profile in VERSION 7

@Thomas Mayer (thomas303)
Thanks. I don't want to file a new ticket because I think the problem is linked to this one. But I try you patch No. 7, and after that I will see. Thank you once more.

@Thomas Mayer (thomas303)

I previously reported (on another page from where I was pointed here) this problem in Ubuntu 12.04.5 LTS. Following suggestion I took the full profile version 7. I did confirm that the problem was apparmor. However with usr.bin.firefox_patched it began throwing parser errors one line at a time.
Without really understanding I began making these mods:
------
17,19c17,18
< #include <abstractions/dbus-strict>
< #include <abstractions/dbus-session-strict>
< #include <abstractions/dconf>
---
> #include <abstractions/dbus>
> #include <abstractions/dbus-session>
25,26d23
< #include <abstractions/ubuntu-unity7-base>
< #include <abstractions/ubuntu-unity7-launcher>
28d24
< #include <abstractions/dbus-accessibility-strict>
------

On the next run there was a complaint about TOK_* things, none of which can be found recursively in my /etc/apparmor.d.

That's where I left it.

I looked at a different platform running Ubuntu 14.04.5 LTS, where Firefox 51.0.1 was updated through apt without problems. But on this platform apparmor is disabled. I did not do that, so I assume that it was shipped with the two symlinks in /etc/apparmor.d/disable. Possibly that was done with a previous update. On that platform I notice a 2014 datestamp on usr.bin.firefox.

I suspect that a substantially different usr.bin.firefox is needed for 12.04 LTS.

Thanks.

Thanks for your help.

@wfhammond

12.04:

My usr.bin.firefox_patched originates from FF package which is shipped with ubuntu 16.04. It is very likely that the apparmor profile shipped with ubuntu 12.04 is different from that version. As a result, the patch seems not to be applicable.

Still good to know for other users.

You can still take the relevant lines from the patch "VERSION 7" and apply them to your usr.bin.firefox.

========

14.04:

Users reported that version 7 worked with 14.04. I have not tested that myself.

Note that FF's apparmor profile is disabled by default (presumably for a long time) via the official packages.

If you want to give it a try (and enable it): The procedure is the same (see comments 31 and 21).

Hi Thomas. Yes, you're right: "the apparmor profile shipped with ubuntu 12.04 is different from that version". I'm using 12.04 LTS Release and after Firefox has been updated to the 49/50/51 versions, I've had to add some rules to the existing Firefox profile (please see: <https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659922> and my last comment # 51.) Everything was related to the e10s and a new Firefox versions.

Anyway, it seems that 12.04 LTS Release have pretty old AppArmor version and rules, such like:

dbus (send)
       bus=session
       peer=(name=org.a11y.Bus),

and so on, mentioned by You (for example; your patch in post # 31 etc.) are not compatible with 12.04 LTS. That's all.

Beat regards.

@anoda Today, the maintainers announced a bugfix release which at least is supposed to fix the "black/white tab issue": https://bugs.launchpad.net/bugs/1659922

They backported it for a release for 12.04, too.

I'm not sure if they applied all the rules FF actually requires, or just a subset of them (e.g. just the black/white tab issue).

Let's see what happens once the new version becomes available via the official package repos.

Hi Thomas. This update was available yesterday (at least for 12.04 LTS Release) and there was only one rule added:

owner /{dev,run}/shm/org.chromium.* rwk,

Which - as I already mentioned - added this a few months ago. (Basically, last year.) So, for me, this update changes nothing. (See: <https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659922> and post # 51.)

Thanks.

@anoda Yes, only the black/white tab issue got fixed with the update which officially got released.

Here's a new patch against the official NEW apparmor profile taken from ubuntu 16.04.

Patch VERSION 8 (please name the version when you reference it somewhere).

And here's the full version with patch VERSION 8 applied. (see https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1659988/comments/21 how to use it).

Hi Thomas. Thanks for a patch, but as I mentioned it earlier; I'm using 12.04 LTS (but preparing to do an update, because of EoL etc.) so I can't use this patch for now in view of, for example:

dbus (send)
       bus=session
       [...]

rules and so on. (As already mentioned; post # 35.) Using these rules will provide an error message during using apparmor_parser(8) to load a "new" Firefox profile into the kernel. But, definitely I'll use your patch after an update :- )

Thanks, best regards.

@anoda Got it. Maybe someone else who also uses 12.04 does the porting. For instance, I don't feel responsible for that (I'm not the package maintainer...).

@Thomas
The official firefox package update issued yesterday fixes my problem (on Firefox 51.0.1, Ubuntu 16.10). Anyway, the usr.bin.firefox apparmor file supplied is quite different from the patched one you shared here with us (and which worked as well). Thank you Thomas again, the bug is fixed for me!

Found another entry in syslog (when starting FF):

Feb 18 06:45:15 lat61 kernel: [ 1123.988918] audit: type=1400 audit(1487396715.969:78): apparmor="DENIED" operation="file_mmap" profile="/usr/lib/firefox/firefox{,*[^s][^h]}//lsb_release" name="/usr/bin/python3.5" pid=4722 comm="lsb_release" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0

Workaround: change

/usr/bin/python3.[0-5] r,

to

/usr/bin/python3.[0-5] rm,

That change is related to this issue: 1659988

Attached: VERSION 9 which contains this change.

Here's the full version of VERSION 9

Hi Thomas.

Firstly; I would like to thank You for all your work. I've had the same issues with Firefox 53. version running on 16.04 LTS Release (see: <https://lists.ubuntu.com/archives/apparmor/2017-May/010731.html>). There was many DENIED entries in log files, such as, /var/log/kern.log and /var/log/syslog containing e.g.: "org.freedesktop.UPower" or "org.gtk.vfs.MountTracker", which appeared always after the very first Firefox start etc.

Unfortunately, I did not find your bug report earlier, but it helped me a lot. So, once again; thank You very, very much :- ) By the way; I think, that Firefox profile needs updates after every new release. There are always some problems/issues with DENIED entries and so on. However, I noticed that some of them do not appear for the second time. (For example; I noticed, that there is "/usr/bin/speech-dispatcher" entry with requested_mask="x" denied_mask="x" but I saw it only once and AppArmor rule for this one, seems to be not necessary.)

Thanks, best regards.

@anoda Yes, on every release of Firefox it is possible that it uses something which is new to the apparmor profile. However, Firefox somehow heals itself in most cases.

I don't get why especially a major browser can't have its apparmor profile enabled by itself. I get that there is a reason for that, however.

[Typo fixed]: I don't get why especially a major browser can't have its apparmor profile enabled by default. I get that there is a reason for that, however.

@anoda Btw: Apparmor log messages sometimes occur for special tasks. Like playing a youtube video, opening a file on disk, etc. Maybe that explains that you see some of these log entries very seldom.

Patch attached fixes a lot, could we have it incorporated yet?

Hello Thomas. Yes, I think you're right; "Apparmor log messages sometimes occur for special tasks." By the way - today I have again an issue (this is happening very often) with the plugin-container (Chrome_ChildThr) segfault. Suddenly, Firefox started to slow down, system also, audio was looping and a mouse moved slowly. After a long while I managed to open terminal and kill Firefox process.

Log file - /var/log/syslog - was full of a known alsa-sink issue. There was also plugin-container (Chrome_ChildThr) entry:

✓ kernel: [24658.609247] plugin-containe[4287]: segfault at 0 ip 800128a8 sp bfdc2430 error 6 in plugin-container[8000f000+1c000]

And... there was also - mentioned in my post #45 - a "/usr/bin/speech-dispatcher" entry! It showed up once again. I was advised that I should create a profile for "speech-dispatcher" and use "Px" rule in a Firefox profile to address this DENIED entry.

However, here is a link to my bug report about plugin-container issues: <https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1656065> All of this is happening on 16.04.2 LTS Release and Firefox 53.0.2 version. I would like to ask: does any of you experienced this problem? I mean: Firefox, system, mouse freeze and a plugin-container segfault?

Thanks, best regards.

@anoda I wrote back via #1656065.

Hello Thomas. Today, I noticed next entry - related with Firefox - in a log files. I'm wondering whether to add this rule, because it's related to the ScreenSaver, which seems to be pretty strange. However a log entry looks this way;

✓ Jun 3 11:45:19 t1aa-kernel dbus[1473]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/ScreenSaver" interface="org.freedesktop.ScreenSaver" member="Inhibit" mask="send" name="org.freedesktop.ScreenSaver" pid=2149 label="/usr/lib/firefox/firefox{,*[^s][^h]}" peer_pid=1612 peer_label="unconfined"

So, the appropriate rule should look like this;

dbus (send)
     bus=session
     interface=org.freedesktop.ScreenSaver
     member=Inhibit,

Thomas, what do You think about; path="/ScreenSaver" entry? Do you think, that "path=/org/freedesktop/ScreenSaver", also should be added, or "interface=" is enough? But, as I wrote - I don't know if it should be added to the Firefox profile. I will keep an eye, on this issue.

Thanks, best regards.