Bug 740057 (selinux_icc) - SELinux is preventing /bin/dbus-daemon from 'read' accesses on the file /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc.
Summary: SELinux is preventing /bin/dbus-daemon from 'read' accesses on the file /home...
Keywords:
Status: CLOSED ERRATA
Alias: selinux_icc
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 16
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:a4b9fcbadda94f69ce539a3c9d9...
: 752193 752194 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-20 19:32 UTC by Mads Kiilerich
Modified: 2011-11-10 16:46 UTC (History)
6 users (show)

Fixed In Version: selinux-policy-3.10.0-32.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-23 04:01:27 UTC


Attachments (Terms of Use)

Description Mads Kiilerich 2011-09-20 19:32:20 UTC
abrt version: 2.0.5
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.1.0-0.rc6.git0.3.fc16.x86_64
reason:         SELinux is preventing /bin/dbus-daemon from 'read' accesses on the file /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc.
time:           Tue Sep 20 21:32:10 2011

description:
:SELinux is preventing /bin/dbus-daemon from 'read' accesses on the file /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc.
:
:*****  Plugin restorecon (99.5 confidence) suggests  *************************
:
:If you want to fix the label. 
:/home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc default label should be icc_data_home_t.
:Then you can run restorecon.
:Do
:# /sbin/restorecon -v /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc
:
:*****  Plugin catchall (1.49 confidence) suggests  ***************************
:
:If you believe that dbus-daemon should be allowed read access on the edid-f96117f183382b871c31aa58fdbe5297.icc file 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 dbus-daemon /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
:Target Context                unconfined_u:object_r:user_home_t:s0
:Target Objects                /home/ccc/.local/share/icc/edid-
:                              f96117f183382b871c31aa58fdbe5297.icc [ file ]
:Source                        dbus-daemon
:Source Path                   /bin/dbus-daemon
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           dbus-1.4.10-3.fc16
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-31.fc16
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP
:                              Fri Sep 16 12:26:22 UTC 2011 x86_64 x86_64
:Alert Count                   1
:First Seen                    Tue 20 Sep 2011 09:24:34 PM CEST
:Last Seen                     Tue 20 Sep 2011 09:24:34 PM CEST
:Local ID                      97ed55b0-8a7e-49e7-b5fa-5c00bc11d09a
:
:Raw Audit Messages
:type=AVC msg=audit(1316546674.876:85): avc:  denied  { read } for  pid=930 comm="dbus-daemon" path="/home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc" dev=sda4 ino=2755380 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
:
:
:type=SYSCALL msg=audit(1316546674.876:85): arch=x86_64 syscall=recvmsg success=yes exit=401 a0=1d a1=7ffffb295170 a2=40000000 a3=0 items=0 ppid=1 pid=930 auid=4294967295 uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 tty=(none) ses=4294967295 comm=dbus-daemon exe=/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
:
:Hash: dbus-daemon,system_dbusd_t,user_home_t,file,read
:
:audit2allow
:
:#============= system_dbusd_t ==============
:allow system_dbusd_t user_home_t:file read;
:
:audit2allow -R
:
:#============= system_dbusd_t ==============
:allow system_dbusd_t user_home_t:file read;
:

Comment 1 Daniel Walsh 2011-09-20 20:11:06 UTC
Why is the dbus-daemon reading this file?  And who created these files.  They are still mislabeled.  Was this a fresh install or did you just update it?

Comment 2 Mads Kiilerich 2011-09-20 21:56:41 UTC
Oh. Ahaa.

I can reproduce this by rebooting and relabelling, enforcing mode, creating a new user on a tty while in gdm, log in as that user ... and boom, this avc and effectively Bug 738803.

When I reproduce it with another new user without rebooting I see no problem.

(When I login as my own user with home on (slow) nfs I see the problem every time ... unless I setenforce 0 ... but that might be a different issue.)

BUT when I disable /etc/xdg/autostart/restorecond.desktop I can reproduce it with new accounts every time. They leave a lot of files incorrectly labelled - including:

restorecon reset /home/zzz/.local/share/icc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0
restorecon reset /home/zzz/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0
restorecon reset /home/zzz/.local/share/icc/edid-217b41bfa44c6012e3120b7588bf9d60.icc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0

Is it some kind of race with restorecon?

The global restorecond service is not enabled. Should it be that?

Comment 3 Adam Williamson 2011-09-21 02:03:18 UTC
anything you had on the system prior to the -31 update won't get fixed by it.

what was broken was a mechanism called 'filetrans' by which the kernel should apply correct labels to newly-created files and directories. it doesn't scan over *existing* ones and fix them. so files that got the wrong labels because they were created while selinux-policy was broken are going to _stay_ broken.

in other words - it's expected that your regular user account will be broken. you'll have to do a 'restorecon -r ~/' to fix it.

however, the case where you create a new user and their files are mislabelled is not expected, and sounds like filetrans still isn't working for you. we might need logs and stuff. I will see if I can recreate.

please disable restorecond for testing; things should work without it, and having it enabled can mask the bug. we don't want to rely on restorecond to make this stuff work.

Comment 4 Mads Kiilerich 2011-09-21 10:06:05 UTC
Adam, I'm not sure what you are telling me or what I can tell that I haven't told already:

I relabeled-on-boot after installing -31, then I added the user and tried to login. restorecond.service wasn't running, and without autostart restorecond.desktop I saw mislabelled files every time - which hints that the reason that it sometimes works is that restorecond.desktop fixes the labels before any harm is done.

Comment 5 Miroslav Grepl 2011-09-21 10:39:29 UTC
Well, then there is something wrong. 

I am pretty sure it was working.

Mads,
what does for you

# sesearch -T -s sysadm_t -t admin_home_t

Comment 6 Miroslav Grepl 2011-09-21 10:56:46 UTC
Actually this sesearch doesn't work for F16.

Comment 7 Miroslav Grepl 2011-09-21 11:45:57 UTC
Ok, I got it.
I need to rebuild checkpolicy. I use my own build which should be the same as the koji build but is not.

Comment 8 Miroslav Grepl 2011-09-21 13:50:11 UTC
Mads,
could you test it with these packages

http://koji.fedoraproject.org/koji/taskinfo?taskID=3367584
http://koji.fedoraproject.org/koji/buildinfo?buildID=264786

Comment 9 Mads Kiilerich 2011-09-21 14:49:18 UTC
+1

checkpolicy-2.1.3-1.2.fc16.x86_64
selinux-policy-targeted-3.10.0-32.fc16.noarch
selinux-policy-3.10.0-32.fc16.noarch

This and other problems seems to be gone now. Thanks!

Comment 10 Fedora Update System 2011-09-21 14:55:57 UTC
selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/FEDORA-2011-13024

Comment 11 Fedora Update System 2011-09-21 22:14:01 UTC
Package selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 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.10.0-32.fc16 checkpolicy-2.1.3-1.2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-32.fc16,checkpolicy-2.1.3-1.2.fc16
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2011-09-23 04:01:07 UTC
selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Daniel Walsh 2011-11-08 19:33:48 UTC
*** Bug 752193 has been marked as a duplicate of this bug. ***

Comment 14 Daniel Walsh 2011-11-08 19:34:59 UTC
*** Bug 752194 has been marked as a duplicate of this bug. ***

Comment 15 Kevin Johnson 2011-11-10 13:52:32 UTC
Experiencing this problem starting yesterday


[kevinj@raykj ~]$ rpm -q selinux-policy
selinux-policy-3.10.0-51.fc16.noarch



[kevinj@raykj ~]$ rpm -q kernel
kernel-3.1.0-1.fc16.x86_64
kernel-3.1.0-5.fc16.x86_64
kernel-3.1.0-7.fc16.x86_64




SELinux is preventing /usr/libexec/colord from read access on the file /home/kevinj/.local/share/icc/edid-f33c31f22efffaff0b2bdf59439bb09e.icc.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label. 
/home/kevinj/.local/share/icc/edid-f33c31f22efffaff0b2bdf59439bb09e.icc default label should be icc_data_home_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /home/kevinj/.local/share/icc/edid-f33c31f22efffaff0b2bdf59439bb09e.icc

*****  Plugin catchall (1.49 confidence) suggests  ***************************

If you believe that colord should be allowed read access on the edid-f33c31f22efffaff0b2bdf59439bb09e.icc file 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 colord /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:colord_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:data_home_t:s0
Target Objects                /home/kevinj/.local/share/icc/edid-
                              f33c31f22efffaff0b2bdf59439bb09e.icc [ file ]
Source                        colord
Source Path                   /usr/libexec/colord
Port                          <Unknown>
Host                          raykj
Source RPM Packages           colord-0.1.13-2.fc16
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-51.fc16
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     raykj
Platform                      Linux raykj 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1
                              21:10:48 UTC 2011 x86_64 x86_64
Alert Count                   12
First Seen                    Wed 09 Nov 2011 04:15:51 PM EST
Last Seen                     Thu 10 Nov 2011 07:51:26 AM EST
Local ID                      b3f27e35-867e-4fd7-ab65-ca157f92c85a

Raw Audit Messages
type=AVC msg=audit(1320929486.41:77): avc:  denied  { read } for  pid=1837 comm="colord" name="edid-f33c31f22efffaff0b2bdf59439bb09e.icc" dev=dm-3 ino=390180 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file


type=SYSCALL msg=audit(1320929486.41:77): arch=x86_64 syscall=open success=no exit=EACCES a0=70bf3a a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=1837 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=colord exe=/usr/libexec/colord subj=system_u:system_r:colord_t:s0-s0:c0.c1023 key=(null)

Hash: colord,colord_t,data_home_t,file,read

audit2allow

#============= colord_t ==============
allow colord_t data_home_t:file read;

audit2allow -R

#============= colord_t ==============
allow colord_t data_home_t:file read;

Comment 16 Daniel Walsh 2011-11-10 14:52:19 UTC
restorecon -R -v /home

Should fix.

Also yum -y update

Comment 17 Kevin Johnson 2011-11-10 15:34:36 UTC
I'm up to date on all my packages, have been since release day.  I see that will "fix" it but not sure why all the sudden this was a problem.  It did prevent login to gnome3 UI for a while -- I ended up having to go to VT to run the restorecon to fix

Comment 18 Daniel Walsh 2011-11-10 16:46:51 UTC
On upgrade the file was label in users homedirs was not fixed.  Once you fix the label everything should be fine.


Note You need to log in before you can comment on or make changes to this bug.