Bug 577911 - Some selinux contexts get spontaneously changed on every reboot
Summary: Some selinux contexts get spontaneously changed on every reboot
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-29 17:05 UTC by Alex Villacís Lasso
Modified: 2010-03-30 15:11 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 15:11:11 UTC
Type: ---


Attachments (Terms of Use)
Sample run of restorecon that shows messed-up contexts that were restored (11.89 KB, text/plain)
2010-03-29 17:05 UTC, Alex Villacís Lasso
no flags Details
Result of restorecon run after first boot with 2.6.32.9-70.fc12.x86_64 (9.88 KB, text/plain)
2010-03-29 21:10 UTC, Alex Villacís Lasso
no flags Details
Result of restorecon run after second boot with 2.6.32.9-70.fc12.x86_64 (350 bytes, text/plain)
2010-03-29 21:10 UTC, Alex Villacís Lasso
no flags Details

Description Alex Villacís Lasso 2010-03-29 17:05:13 UTC
Created attachment 403326 [details]
Sample run of restorecon that shows messed-up contexts that were restored

Description of problem:
After installing the latest selinux-policy-* for Fedora 12, I have noticed that some random SELinux contexts get changed on files on every reboot. This results in random problems arising from denial of access to system files or directories, or denied capabilities. 

Some of the symptoms I have experienced so far (not all at the same time):
Failure to start auditd daemon (denied access to /var/log/audit/audit.log)
Failure to start nmb daemon (denied access to /var/lib/samba/browse.dat*)
Failure to start gdm and graphic session (denied access to /etc/group)
Failure to determine hostname on apache/sendmail/cups (denied access to /etc/hosts)

I have found the following workaround: log in text console as root, and run restorecon -r on the entire filesystem. This restores a bunch of changed contexts, but only works until the next reboot.

Version-Release number of selected component (if applicable):
selinux-policy-3.6.32-103.fc12.noarch
selinux-policy-targeted-3.6.32-103.fc12.noarch

How reproducible:
Almost always

Steps to Reproduce:
1.Install mentioned versions of packages
2.Reboot (several times if necessary)
3.Monitor boot process and contexts
  
Actual results:
File contexts get changed on reboot on a seemingly random way, and cause various symptoms arising from denied access to various system components.

Expected results:
No spontaneous changes to selinux contexts on reboot

Additional info:
This problem might explain the following bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=577890
https://bugzilla.redhat.com/show_bug.cgi?id=577520
https://bugzilla.redhat.com/show_bug.cgi?id=577519

Comment 1 Daniel Walsh 2010-03-29 17:23:39 UTC
None of these bugs are caused by labeling problems, I believe.  Although 577890 could be.

Are you seeing the above attachment of bad context on each reboot?  Or was this run from the first time?

Comment 2 Daniel Walsh 2010-03-29 17:26:03 UTC
Any chance you were using livecd or mock?

Comment 3 Stephen Smalley 2010-03-29 17:44:19 UTC
running kernel version (uname -r)?
filesystem type? (cat /proc/mounts)

Comment 4 Alex Villacís Lasso 2010-03-29 18:15:45 UTC
The attached report is from my work machine.

I use my work machine (normally left on all night) to download the Fedora updates, apply them on the work days, and batch them all to apply them to my home machine (shut down every night) on weekends. I have been running kernel 2.6.34-rc2 on both home and work. I have been seeing this labeling problem on my work machine since I updated selinux-policy-* on March 23-24. Right after rebooting my machine, I got the /etc/group denial problem. I applied restorecon /etc/group to be able to work again. My home machine did not experience labeling problems until I applied the batch of updates from my work machine, which included selinux-policy-*. I must note that I do not suspect the custom kernel to be at fault, since my home machine ran it just fine before the updates.

On work machine:
rootfs / rootfs rw 0 0
/proc /proc proc rw,relatime 0 0
/sys /sys sysfs rw,seclabel,relatime 0 0
udev /dev tmpfs rw,seclabel,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
/dev/sda2 / ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
none /selinux selinuxfs rw,relatime 0 0
/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0
/dev/sda1 /boot ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
/dev/sda5 /home ext3 rw,seclabel,relatime,errors=continue,user_xattr,acl,data=ordered 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
gvfs-fuse-daemon /home/alex/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0

Both work and home machine are previously-working Fedora 12 x86_64 machines, installed into hard disk.

The attached restorecon report was generated today (March 29) at my work machine.

Comment 5 Daniel Walsh 2010-03-29 18:36:03 UTC
I had seen some problems with kernel
2.6.34-rc2

Could you try to boot with the f12 kernel. Fix the labels and then reboot, and see if the labels are screwed up.

I was playing around with this kernel also, but simultaneosly with livecd and mock,  I blamed them for screwing up the labels, but it could very well be the kernel.  I booted F13 kernel and the labels are not getting mixed up.

Comment 6 Daniel Walsh 2010-03-29 19:56:11 UTC
Now I can't get it to happen with that kernel.  I will install fc2 and try livecd-creator again.

Comment 7 Alex Villacís Lasso 2010-03-29 21:10:24 UTC
Created attachment 403364 [details]
Result of restorecon run after first boot with 2.6.32.9-70.fc12.x86_64

Comment 8 Alex Villacís Lasso 2010-03-29 21:10:53 UTC
Created attachment 403365 [details]
Result of restorecon run after second boot with 2.6.32.9-70.fc12.x86_64

Comment 9 Alex Villacís Lasso 2010-03-29 21:13:00 UTC
As requested, I fixed the labels after a boot with the fc12 kernel, then rebooted again to check what happened. A bunch of labels were restored after the first boot. Just two were restored at the second boot. However, I am not entirely convinced that this is a kernel problem. The restorecon after the second boot shows two files that were supposed to be already fixed in the first restorecon.

Comment 10 Eric Paris 2010-03-29 21:48:21 UTC
A separate reporter seems to have found a problem with how ext3 is handling things in 2.6.34 and reports that fixing that issue made the random labels go away.  Believing it to be a 2.6.34 kernel problem also explains why you didn't have the craziness on the 32 kernel (the xorg lock one is normal, but I don't know what backuppc is doing, it could be normal as well)

As soon as I have a public posting to a patch I'll notate it here.  For now it looks like an issue with commit 9df93939b73

Comment 11 Eric Paris 2010-03-30 00:16:15 UTC
Fix is committed in Linus's tree

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=de329820e920cd9cfbc2127cad26a37026260cce

Why don't you give a kernel with that patch a try and tell us what you see.  Thanks for the report!

Comment 12 Daniel Walsh 2010-03-30 13:14:11 UTC
restorecon reset /etc/BackupPC/pc context system_u:object_r:httpd_sys_content_rw_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0
restorecon reset /tmp/.X0-lock context system_u:object_r:xdm_tmp_t:s0->system_u:object_r:xserver_tmp_t:s0

httpd_sys_content_rw_t == httpd_sys_script_rw_t 
and
xdm_tmp_t == xserver_tmp_t

They are aliases of each other in policy.

Sadly restorecon has no way of knowing this.

I will fix the labeling in policy.

/etc/BackupPC/pc is provided in the BackupPC package, so I can not fix that one.

In reality the labelling is correct.

Comment 13 Eric Paris 2010-03-30 15:11:11 UTC
Fixed in latest F14 kernels.

http://koji.fedoraproject.org/koji/buildinfo?buildID=164438


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