Bug 1041345

Summary: SELinux is preventing /usr/bin/gnome-keyring-daemon from using the 'setcap' accesses on a process.
Product: [Fedora] Fedora Reporter: Amit Shah <amit.shah>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: amit.shah, dominick.grift, dwalsh, lvrabec, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:0ad4d07a7043c1a5d59237905a2493b86dc8a7859477d2c3e53ebcba0c50401d
Fixed In Version: selinux-policy-3.12.1-116.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-16 07:09:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Amit Shah 2013-12-12 15:23:07 UTC
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

Comment 1 Miroslav Grepl 2013-12-12 16:14:48 UTC
Hod did you get this one? I believe you use bad sandbox_web_client_t sandbox type.

Comment 2 Miroslav Grepl 2013-12-12 16:16:07 UTC
*** Bug 1041347 has been marked as a duplicate of this bug. ***

Comment 3 Amit Shah 2013-12-16 12:25:01 UTC
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.

Comment 4 Daniel Walsh 2013-12-16 15:25:08 UTC
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.

Comment 5 Amit Shah 2013-12-16 19:46:44 UTC
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.

Comment 6 Daniel Walsh 2014-01-03 20:07:10 UTC
49a4c25a846f475b5d36ad422274f592e751c45b allows this access in git.

Comment 7 Lukas Vrabec 2014-01-04 00:03:59 UTC
back ported.

Comment 8 Fedora Update System 2014-01-13 22:55:46 UTC
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

Comment 9 Fedora Update System 2014-01-15 05:57:26 UTC
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).

Comment 10 Fedora Update System 2014-01-16 07:09:57 UTC
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.