Description of problem: The program /usr/lib64/qt5/libexec/QtWebEngineProcess is causing hundreds of SECCOMP audit events. type=SECCOMP msg=audit(04/04/2017 19:42:17.855:1177) : auid=sgrubb uid=sgrubb gid=sgrubb ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=4270 comm=QtWebEngineProc exe=/usr/lib64/qt5/libexec/QtWebEngineProcess sig=SIG0 arch=x86_64 syscall=open compat=0 ip=0x7fb21feb6c7a code=errno # ausearch --start 19:17 -m seccomp --raw | aureport --syscall --summary -i Syscall Summary Report ========================== total syscall ========================== 85 open 5 set_robust_list SECCOMP events means that someone decided to try to confine the process but its violating the policy. The effect is just a bad errno so the syscall probably completes. But its definitely saying the policy needs to be fixed. Version-Release number of selected component (if applicable): qt5-qtwebengine-5.7.1-4.fc25.x86_64 How reproducible: Always Steps to Reproduce: 1. Have auditing enabled 2. Run kontact and receive email. 3. Run ausearch --start today -m seccomp
Here's a better view of all the seccomp violations: # ausearch --start 04/04/2017 19:17 -m seccomp --raw | aureport --syscall --summary -i Syscall Summary Report ========================== total syscall ========================== 228 open 47 set_robust_list 16 sched_getparam 16 sched_getscheduler 8 fchmod 6 sched_getaffinity [root@x2 ~]# ausearch --start 04/04/2017 19:17 -m seccomp --raw | aureport -x --summary -i Executable Summary Report ================================= total file ================================= 321 /usr/lib64/qt5/libexec/QtWebEngineProcess
Is this still happening with 5.9.1?
Yes. The audit command is above if you want to check this on your system. I think that the seccomp feature is not fully cooked. I applaud the intent, but with this many violations, the policy being enforced does not match the normal daily operations of the code. # ausearch --start yesterday -m seccomp --raw | aureport -s -i --summary Syscall Summary Report ========================== total syscall ========================== 588 open 372 set_robust_list 36 fchmod 26 sched_getaffinity 1 execve A policy with that many violations should not be enabled.
> A policy with that many violations should not be enabled. It should. The point is to protect the users against malicious websites. The calls blocked by seccomp are likely in some (system or bundled) libraries and not necessary to render the websites at all. So the issue is that they are getting audited, which is likely not what Chromium upstream intended (they should just be silently rejected).
The only KDE program I have running is Kontact. So, this is all about processing email. And by the way, Kontact has all kinds of problems crashing. I wonder sometimes if these are related. But about the policy, Kontact is not asking this component to make random syscalls. If its forbidden to call sched_getaffinity, then why did QtWebEngineProcess have that code in its sources? And perhaps set_robust_list failures is why I get a lot a racy lock ups and crashes. I can't see how blocking thread sync primitives is good for security. :-) https://bugs.kde.org/show_bug.cgi?id=377395 There are a lot of other crashes/bugs kontact is experiencing: https://bugs.kde.org/show_bug.cgi?id=378678 https://bugs.kde.org/show_bug.cgi?id=377590 https://bugs.kde.org/show_bug.cgi?id=378172 https://bugs.kde.org/show_bug.cgi?id=377982 This all started around April 2. I don't know if that helps pin it down.
> The only KDE program I have running is Kontact. So, this is all about > processing email. Well, yes, Kontact/KMail uses QtWebEngine to display HTML mail, and I think also to format the headers of plain text mail. > And by the way, Kontact has all kinds of problems crashing. I wonder sometimes > if these are related. I doubt it. The bugs you link to are all in the main Kontact/KMail process, which is a separate process from the QtWebEngineProcess. > But about the policy, Kontact is not asking this component to make random > syscalls. If its forbidden to call sched_getaffinity, then why did > QtWebEngineProcess have that code in its sources? And perhaps set_robust_list > failures is why I get a lot a racy lock ups and crashes. Because the code that does that is in some library, not in Chromium/QtWebEngine itself. > I can't see how blocking thread sync primitives is good for security. :-) I guess the policy can probably be safely relaxed in some places. > This all started around April 2. I don't know if that helps pin it down. That would be the QtWebEngine 5.8.0 update. So 5.7.1 had no seccomp failures? Interesting.
The only seccomp failures I see on April 1 and prior is from /usr/libexec/tracker-extract.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. 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 '25'. 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 25 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.
I have gotten 3500 seccomp events today. This problem still exists. I still think the seccomp policy is wrong. This is what I see today: 1692 stat 846 set_robust_list 807 open 56 fchmod 50 sched_getaffinity This is all generated in relation to email - not browsing the web.
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.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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.