Ubuntu
apparmor package

Bug that stops flash plugin to work in firefox profile; logs provided.

Asked by Devin

Every time I open Firefox apparmor-notify displays a deny message of type "m" access to "/dev/zero". I added the line "/dev/zero m," to my /etc/apparmor.d/usr.bin.firefox profile to be able to play Adobe Flash videos, which it can now do after doing that. Question #1: What security risks play a role when I allow "m" (?) access to this folder for Firefox and do the benefits outway the risk to the sandbox?

After I updated my apparmor profile to allow flash videos, I no longer receive a deny message for it at every Firefox startup, but I now get a deny message of “rw” (read and write) to “/dev/nvidiactl”. Question #2: Is it okay to do that (i.e. add line "/dev/nvidiactl rw," to the Firefox profile configuration for apparmor), what are the security risks of doing so, and what purpose is such a permission good for?

What I want to add to a Wishlist for the apparmor package: enable apparmor sandboxing for Firefox to every Ubuntu user once the flash gets fixed after the quoted bugs below are patched.

Here is the log that I get before I add the permission in the apparmor firefox profile to get flash to work,
"
Mar 29 17:11:53 username kernel: [27877.596655] type=1400 audit(1333066313.785:410): apparmor="DENIED" operation="file_mmap" parent=4670 profile="/usr/lib/firefox-11.0/firefox{,*[^s][^h]}" name="/dev/zero" pid=4673 comm="firefox" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
"
Here is the log that I get after I add the permission in the apparmor firefox profile even though by this time flash started working,
"
Mar 25 19:26:29 username kernel: [21002.394793] type=1400 audit(1332728789.574:427): apparmor="DENIED" operation="open" parent=4894 profile="/usr/lib/firefox-11.0/firefox{,*[^s][^h]}" name="/dev/nvidiactl" pid=4897 comm="firefox" requested_mask="rw" denied_mask="rw" fsuid=1000 ouid=0
"

Question information

Language:
English Edit question
Status:
Answered
For:
Ubuntu apparmor Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
daniel CURTIS (anoda) said : 		#1

Hi Devin,

You have written, that apparmor-notify create a message about denying "m" access to '/dev/zero'. You also asked about security risk for this configuration. Let see; "m" (mmap) option used in '/dev/zero' - this means, that the program running under the profile can access the resource using the mmap system call with the flag PROT_EXEC. This means, that the data can be executed.

In my opinion, it may have an impact on safety, because of the possibilities: access and execute provided by "m" option. I'm using the default Firefox profile (with small changes related to @HOME directory etc. nothing big) and I never added something like 'dev/zero', because everything - flash etc. - worked okay from the beginning. Please also note, that in the default Firefox profile, there is no such rule. So personally, I would not add this option.

If it is about '/dev/nvidiactl' - I have the same AppArmor behaviour. I also wondering, whether this has any effect on safety. So, if everything works fine with the default Firefox profile (e.g. flash, downloading, uploading files etc.) I think it is a good AppArmor action. I think, that if it would be important, then it should be added to the default profile. This is my opinion, and I could be wrong! Remember that!

Revision history for this message
Devin (8basepairs) said : 		#2

Now that I know access to /dev/zero is not ordinary, I believe the unauthorized access is caused by dnscrypt-proxy since I started using it within weeks of filing this bug. I stopped using apparmor after I filed this report since it causes flash video to fail. I hope giving the name of the dnscrypt-proxy package will help the apparmor team to figure out where to start to resolve this issue. By the way, I have more recently moved to Fedora, so I doubt I can continue helping you with the same bug report exactly especially since I have not tried apparmor since my switch (something I think I should try now...). Let me know if I can further help you.

Revision history for this message
A. Denton (aquina) said : 		#3

Question seems to be a duplicate of #191710. Therefore CLOSE requested.

Can you help with this problem?

Provide an answer of your own, or ask Devin for more information if necessary.

To post a message you must log in.