Comment 11 for bug 1777070

Revision history for this message
John Johansen (jjohansen) wrote : Re: [apparmor] [Bug 1777070] Re: firefox plugin libwidevinecdm.so crashes due to apparmor denial

On 10/25/20 5:15 AM, baptx wrote:
> I got it working by adding the 2 lines at the end of the
> /etc/apparmor.d/usr.bin.firefox just before the closing brack "}".
> Without these lines, I had to use another workaround by disabling
> Apparmor completely on Firefox with a command like "sudo aa-complain
> /usr/lib/firefox/firefox" or using the official Firefox binary from
> Mozilla instead of the Ubuntu package.
>
> I saw Daniel wrote "this is not a great way of working (malware could
> write to that location and then load in code)" but do you have an idea
> how to make it more secure?
>
I assume by the 2 lines you mean

ptrace (trace) peer=@{profile_name},
@{HOME}/.mozilla/firefox/*/gmp-widevinecdm/*/lib*so m,

from the bug report. Neither of these lines would allow malware to
write to that location. However they do provide some danger.

The first rule allow firefox to ptrace it self, this could potentially
be exploited by injected shell code to further take control of firefox
if say the code gains control of the render process. It won't however
allow removing confinement or attacking other processes the user might
be running.

The second rule allows firefox to load and run code from that location.
But doesn't allow firefox to write to it. So if there is malware on the
system that can write to that location it could have firefox run it.
But if something manages to hack/inject code into firefox it won't be
able to put code there. Dealing with this in apparmor comes down to
making sure the rest of the system confinement is correct, preventing
said malware from writing to that location. Or you could potentially
use IMA to further restrict and only allow signed files from this
location.

The reason this is more dangerous than allowing /lib/*.so or other
system locations is the users home directory can be written by other
processes run by the user. And on most systems, most user processes
are running unconfined hence malware that exists on the system and
isn't confined could write to it.

Again this isn't some much a problem with having the rule in the
apparmor profile but have sufficient policy on the system.

> When will the fix be added officially to the Firefox Apparmor profile?
>
these can be added fairly soon.
https://gitlab.com/apparmor/apparmor/-/merge_requests/684

though that is just landing it upstream and I am not sure when the
next ubuntu upload will be