Bug 740057 (selinux_icc)

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?

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?

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.

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.

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

Actually this sesearch doesn't work for F16.

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.

Mads,
could you test it with these packages

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

+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!

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

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).

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.

*** Bug 752193 has been marked as a duplicate of this bug. ***

*** Bug 752194 has been marked as a duplicate of this bug. ***

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;

restorecon -R -v /home

Should fix.

Also yum -y update

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

On upgrade the file was label in users homedirs was not fixed.  Once you fix the label everything should be fine.