Description of problem: SELinux is preventing /usr/bin/gnome-keyring-daemon from using the 'setcap' accesses on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that gnome-keyring-daemon should be allowed setcap access on processes labeled sandbox_web_client_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep gnome-keyring-d /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:sandbox_web_client_t:s0: c266,c705 Target Context unconfined_u:unconfined_r:sandbox_web_client_t:s0: c266,c705 Target Objects [ process ] Source gnome-keyring-d Source Path /usr/bin/gnome-keyring-daemon Port <Unknown> Host (removed) Source RPM Packages gnome-keyring-3.10.1-1.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-12-12 20:28:51 IST Last Seen 2013-12-12 20:28:51 IST Local ID 498d43d1-5216-4a46-bc43-48d565d3badb Raw Audit Messages type=AVC msg=audit(1386860331.684:40079): avc: denied { setcap } for pid=8460 comm="gnome-keyring-d" scontext=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c266,c705 tcontext=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c266,c705 tclass=process type=SYSCALL msg=audit(1386860331.684:40079): arch=x86_64 syscall=capset success=no exit=EACCES a0=7fb8ed638814 a1=7fb8ed63881c a2=7fb8eb550778 a3=7fff534a1530 items=0 ppid=8459 pid=8460 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=1 tty=(none) comm=gnome-keyring-d exe=/usr/bin/gnome-keyring-daemon subj=unconfined_u:unconfined_r:sandbox_web_client_t:s0:c266,c705 key=(null) Hash: gnome-keyring-d,sandbox_web_client_t,sandbox_web_client_t,process,setcap Additional info: reporter: libreport-2.1.9 hashmarkername: setroubleshoot kernel: 3.11.10-301.fc20.x86_64 type: libreport
Hod did you get this one? I believe you use bad sandbox_web_client_t sandbox type.
*** Bug 1041347 has been marked as a duplicate of this bug. ***
I did have a firefox instance running inside a sandbox_web_t sandbox, but I thought this was outside the sandbox (on the desktop itself)? Not really sure how this one popped up. Could be a mix of resuming from suspend, asking g-o-a to sign into kerberos (on the desktop), not really sure. Also, setroubleshootd (along with journalctl) was taking 100% CPU for some reason for a really long while. Was burning up my battery pretty fast.
amit are you seeing other AVC's? setroubleshoot sends avc messages to journal, so if you had an infinite amount of AVC's it could cause this problem.
The sealert gui was only showing these three, but in a loop: by the time I delted one, there were 4 more added to the queue, and it was running continously. At that point, I tried kill -9 setroubleshootd, didn't work. There was no g-o-a process, so I was just trying to do something that would free up my CPU so that I could do something interesting. journalctl too was showing lots and lots repeated AVCs. I think I just did a pkill -SIGSTOP setroubleshootd, and filed these bugs and moved on. A pkill -SIGCONT setroubleshootd sometime later did not bring the erratic behaviour back. Some text from journalctl around that time is pasted here Dec 12 20:55:12 grmbl.mre setroubleshoot[30290]: SELinux is preventing /usr/libexec/goa-daemon from read access on the key . For complete SELinux messages. run seale Dec 12 20:55:12 grmbl.mre python[30290]: SELinux is preventing /usr/libexec/goa-daemon from read access on the key . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that goa-daemon should be allowed read access on the key by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep pool /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp I counted something like 16 of these AVCs in one second. And this happened over several minutes.
49a4c25a846f475b5d36ad422274f592e751c45b allows this access in git.
back ported.
selinux-policy-3.12.1-116.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-116.fc20
Package selinux-policy-3.12.1-116.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-116.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-116.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.