Description of problem: The firefox program appears to be using libseccomp filtering. However, its filling up audit logs with events. They look like this: type=SECCOMP msg=audit(10/29/2017 10:12:34.410:1022) : auid=sgrubb uid=sgrubb gid=sgrubb ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2548 comm=Web Content exe=/usr/lib64/firefox/firefox sig=SIG0 arch=x86_64 syscall=stat compat=0 ip=0x7f74e1e7fd15 code=trap Over the period of an hour, it generated over 25,000 events: $ ausearch --start today -m seccomp -x firefox --raw | aureport --summary --syscall -i Syscall Summary Report ========================== total syscall ========================== 15346 stat 6027 open 3833 unlink 13 access 12 readlink While seccomp filtering is there to prevent unexpected syscalls due to maliscious activity, a program must be checked to see that under normal operation is doesn't generate any events. It seems perfectly reasonable to be able to call stat or open or unlink. Please check that the filter actually needs to prevent those syscalls. Version-Release number of selected component (if applicable): firefox-56.0-5.fc26.x86_64
I am not seeing any of these on Firefox 56 or 57 (both on Fedora 26). Can you please try to reproduce with a fresh profile?
Just noticed this too while listening to Spotify web client (which uses Widevine): as long as a stream is playing there's a non-stop stream of SECCOMP events in the log, keeping the whole system rather busy while updating the log. # ausearch --start today -m seccomp -x firefox --raw|aureport --syscall -i --summary Syscall Summary Report ========================== total syscall ========================== 48279 stat 48276 openat 48184 unlink 37 access 10 open 2 readlink This is on Fedora 27, firefox-58.0.2-1.fc27.x86_64, the profile started from scratch two weeks ago. Incidentally the reason for painfully restarting with a fresh profile was to make Bluejeans Primetime and Spotify to work after a long long break...
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still happens in Fedora 28, firefox-59.0.2-1.fc28.x86_64.
I don't see that on firefox-60.0.1-3.fc28.x86_64 when listening on Spotify. Can you confirm the fix?
Still getting them on firefox-60.0.1-1.fc28.x86_64. The fixes between 1-3 don't seem related at all.
Hm, I realize that those are actually a SELinux messages and not related to Firefox sandbox itself. Moving to SELinux then.
Hello Martin, No these are not related to selinux. Changing it back to firefox. These would be be syscall events that someone at mozilla decided to block via seccomp. However, they did it in a way that generates events. Meaning that they do not understand all the things that firefox wants to do. [sgrubb@x2 ~]$ ausearch --start today -m seccomp --raw | aureport -x --summary Executable Summary Report ================================= total file ================================= 263991 /usr/lib64/firefox/firefox 352 /usr/lib64/qt5/libexec/QtWebEngineProcess $ ausearch --start today -m seccomp -x firefox --raw | aureport --syscall --summary -i Syscall Summary Report ========================== total syscall ========================== 93683 stat 89400 openat 81316 unlink 104 readlink 80 access 14 mkdir 9 socket 9 connect 8 statfs 4 socketpair Has this topic even been discussed upstream? It is filling up logs. Thanks!
(In reply to Steve Grubb from comment #8) > Hello Martin, > > No these are not related to selinux. Changing it back to firefox. These > would be be syscall events that someone at mozilla decided to block via > seccomp. However, they did it in a way that generates events. Meaning that > they do not understand all the things that firefox wants to do. > > [sgrubb@x2 ~]$ ausearch --start today -m seccomp --raw | aureport -x > --summary > > Executable Summary Report > ================================= > total file > ================================= > 263991 /usr/lib64/firefox/firefox > 352 /usr/lib64/qt5/libexec/QtWebEngineProcess > > $ ausearch --start today -m seccomp -x firefox --raw | aureport --syscall > --summary -i > > Syscall Summary Report > ========================== > total syscall > ========================== > 93683 stat > 89400 openat > 81316 unlink > 104 readlink > 80 access > 14 mkdir > 9 socket > 9 connect > 8 statfs > 4 socketpair > > Has this topic even been discussed upstream? It is filling up logs. Thanks! Okay, I don't say I understand it either. But I wonder why I don't see that in my log? (I admit I have SELinux disabled). How can I reproduce that? Do I need to enable SELinux or so?
(In reply to Martin Stransky from comment #9) > Okay, I don't say I understand it either. But I wonder why I don't see that > in my log? (I admit I have SELinux disabled). How can I reproduce that? Do I > need to enable SELinux or so? Having SELinux disabled seem like a very wrong thing to do. Anyway, I'm not seeing any seccomp events. Both commands in comment #8 only print this info: no events of interest were found Also, /var/log/audit/audit.log does not contain any seccomp events related to firefox except for crashes (type=ANOM_ABEND). @reporter: Can you also see those seccomp events in Firefox' about:support page? Is it possible that you changed any preferences related to seccomp on either your distro or firefox?
SELinux really is not related at all. Not seeing those SECCOMP messages is caused by this default in Fedora /etc/audit/rules.d/audit.rules (see bug 1117953): # This suppresses syscall auditing for all tasks started # with this rule in effect. Remove it if you need syscall # auditing. -a task,never Some of us need audit doing its job though... So to reproduce, comment that out, restart auditd (or do "auditctl -d never,task" to temporary enable), restart Firefox and enjoy. Note that it's not just Spotify spewing out those messages, merely starting up Firefox and just regular browsing causes plenty of them. But streaming media, whether Spotify, Youtube or whatever makes it go *crazy*.
(In reply to Christian Stadelmann from comment #10) > (In reply to Martin Stransky from comment #9) > > Okay, I don't say I understand it either. But I wonder why I don't see that > > in my log? (I admit I have SELinux disabled). How can I reproduce that? Do I > > need to enable SELinux or so? > > Having SELinux disabled seem like a very wrong thing to do. > > Anyway, I'm not seeing any seccomp events. Both commands in comment #8 only > print this info: no events of interest were found You need to have auditing enabled. > Also, /var/log/audit/audit.log does not contain any seccomp events related > to firefox except for crashes (type=ANOM_ABEND). Those would likely be segfaults...which sounds bad also. > @reporter: Can you also see those seccomp events in Firefox' about:support > page? Yes, I do. Its at the bottom and called sandboxing. > Is it possible that you changed any preferences related to seccomp on > either your distro or firefox? No, I have not. This is a default setting. Sandbox Seccomp-BPF (System Call Filtering) true Seccomp Thread Synchronization true User Namespaces for privileged processes true User Namespaces false Content Process Sandboxing true Media Plugin Sandboxing true Content Process Sandbox Level 4 Effective Content Process Sandbox Level 4 Under the rejected syscalls, I see nothing. The problem is that simply intercepting the syscall with a trap operation (SECCOMP_RET_TRAP) causes an audit event.
(In reply to Steve Grubb from comment #12) > (In reply to Christian Stadelmann from comment #10) > > Is it possible that you changed any preferences related to seccomp on > > either your distro or firefox? I meant the audit config. Your /etc/audit/audit.rules is changed from the default, that's why Martin Stransky does not see those events but you do.
(In reply to Christian Stadelmann from comment #13) > (In reply to Steve Grubb from comment #12) > > (In reply to Christian Stadelmann from comment #10) > > > Is it possible that you changed any preferences related to seccomp on > > > either your distro or firefox? > > I meant the audit config. Your /etc/audit/audit.rules is changed from the > default, that's why Martin Stransky does not see those events but you do. Yes, my audit rules are different that default. Panu correctly identified the problem. Fedora requires the audit system to be shipped in a way that it does not work. You have to undo that damage to have a working audit system. Once you do that, seccomp events come pouring in. There are no audit rules that specifically allow seccomp events. You cannot control it in the same way that cannot make an selinux AVC show up in your logs. It is the application (Firefox) that asks for SECCOMP_RET_TRAP which in turn triggers audit events at a high rate. SECCOMP_RET_TRAP is usually used for debugging so that you do not disallow something while policy is being written. To make this go away, seccomp BPF policy probably needs to get updated with these expected syscalls.
I'm really not an expert here so I'd appreciate your suggestion how to handle this.
I think upstream started working on a sandbox but never updated the rules with what the system normally calls. I don't have any idea what their plan was and how long they wanted to collect data to inform what the policy should be. I did a little poking around in firefox bugzilla and they have quite a few bugs against the sandbox. But nothing about flooding audit logs.
Filed upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1465152
I responded in the Mozilla bug, but to summarize: the use of SECCOMP_RET_TRAP in Firefox is very much intentional; it's for what seccomp-bpf's original author[*] termed “in-process system call emulation”, specifically to handle areas of policy that seccomp-bpf can't express directly. You'll need to exclude Firefox from this logging (including the plugin-container executable, which is used for EME CDMs; it's much lower-volume, but you're going to see a few openat()s and perhaps a uname()), and if it's possible to not log SECCOMP_RET_TRAP at all (or only opt-in for policies known not to use it in normal operation) you might want to consider that. [*] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb6ea4301a1109afdacaee576fedbfcd7152fc86
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.