This was observed in the ia64 development tree. Some RPM versions: [root@minime1 ~]# rpm -qa | grep selinux selinux-policy-targeted-1.25.4-2 libselinux-devel-1.25.2-1 libselinux-1.25.2-1 [root@minime1 ~]# rpm -q kernel initscripts kernel-2.6.12-1.1485_FC5 initscripts-8.11.1-1 As far as I could tell from reading and documentation, if you boot with "autorelabel" or touch "/.autorelabel"... the next boot of the system should relabel. This works fine. However, after the system is re-labeled, it continues with the boot up process. When I get the login prompt, I'm unable to log in (shell permission denied). If I reset the machine, the _next_ boot works fine. In other words, it seems like the relabeling doesn't fix things until yet another reboot is done. Here is how I produced this: - I installed a ia64 development system - I augmented the install with system-config-packages (because only minimal installs can happen at the moment) - I use a custom system imager setup (mainly rsync under the covers) to create a duplicate of the root drive and populate a new system with it. - At that point, you have to re-label the files on the new target system. - Notice that even if you boot with autorelabel or /.autorelabel, you still can't log in until you reboot one more time. Please help this bug find the right group; I wasn't sure. Also, I set it as ia64 specific but I haven't tested the development tree for x86. I'd be happy to do some new tests.
Thank you for the report. I saw users mentioning this on IRC but none seems to have reported this. Changing component to selinux-policy-targeted as that seemed more appropriate. Changing status to assigned Might useful to check if its reproducible on other arch's
I could try to re-produce this on an x86 system tonight. My imaging system here isn't implemented for x86 but my idea is to install FC development on to the an x86 system and dump/restore it to another partition on the same machine. I'd then assume that booting the "copied" new partition should result in similar issues that I saw on ia64. If that sounds like a good approach, I'll look in to doing it tonight.
Yes, I would like to see the AVC message you get when you can not login.
My first experiment with x86 didn't duplicate the problem. I installed, then dumped the root to a backup root. I booted with the backup root... I didn't have to re-label anything in this case. I'm going to try a couple more things before I give up here.
Ok, I duplicated this for x86. dump must be "too good" for duplicating this problem. However, many sites use System Imager which makes use of rsync. In my second test, I replicated the root device using rsync to to the backup root filesystem. I fixed the fstab up, then booted from it. The rsync command I think I used (from memory) was: rsync -avHvxz / /root2 The first boot on the backup root after this rsync command showed I could not log in. I booted from the backup root again, this time with the "autorelabel" option. It generated new labels and eventually the login prompt was back. I was still unable to log in to the console (vc1) just like I had trouble on ia64. Here is an attempt with ssh (matching what I saw on ia64): root@bammbamm's password: Last login: Wed Aug 17 18:03:20 2005 /bin/bash: Permission denied Connection to bammbamm closed. Just as in the ia64 case, after I rebooted a second time, everything was fine on the backup root. I went back in to the messages file and found these entries that seem to be of interest: Aug 17 18:03:18 bammbamm login(pam_unix)[2012]: session opened for user root by (uid=0) Aug 17 18:03:18 bammbamm login[2012]: Warning! Could not relabel /dev/tty1 with root:object_r:tty_device_t, not relabeling.Permission denied Aug 17 18:03:18 bammbamm -- root[2012]: ROOT LOGIN ON tty1 Aug 17 18:03:18 bammbamm login(pam_unix)[2012]: session closed for user root Aug 17 18:03:20 bammbamm login(pam_unix)[2263]: session opened for user root by (uid=0) Aug 17 18:03:20 bammbamm login[2263]: Warning! Could not relabel /dev/tty1 with root:object_r:tty_device_t, not relabeling.Permission denied Aug 17 18:03:20 bammbamm -- root[2263]: ROOT LOGIN ON tty1 Aug 17 18:03:20 bammbamm login(pam_unix)[2263]: session closed for user root Aug 17 18:09:45 bammbamm sshd(pam_unix)[2320]: session opened for user root by root(uid=0) Aug 17 18:10:57 bammbamm login(pam_unix)[2265]: session opened for user root by (uid=0) Aug 17 18:10:57 bammbamm login[2265]: Warning! Could not relabel /dev/tty1 with root:object_r:tty_device_t, not relabeling.Permission denied
I don't know what you mean by the autorelabel option. There is no autorelabel option to the kernel that I am aware of. Creating a /root2/.autorelabel and booting with that root should cause the relabel to happen successfully. Are you seeing any AVC messages in /var/log/messages or /var/log/audit/audit.log? Dan
Regarding autorelabel - you can pass it as a kernel option and it has the same affect as creating the file. From /etc/rc.d/rc.sysinit ($cmdline is set to /proc/cmdline earlier in the script): # Check to see if a full relabel is needed if [ -n "$SELINUX" ]; then if [ -f /.autorelabel ] || strstr "$cmdline" autorelabel ; then relabel_selinux fi Regarding the messages - I included the messages I thought were interesting. I can repeat the test and just save the full /var/log/messages and audit.log if you like. I think they're long gone now on that machine :)
I never noticed that, thanks. Yes I could use the AVC messages from both those files or just attach them if they are small.
Created attachment 118020 [details] /var/log/messages from problem root /var/log/messages from problem root, one more attachment to go.
Created attachment 118021 [details] /var/log/audit/audit.log from problem root Here is the audit.log from the problem root. Please note: I didn't change the OS level, I just re-ran the test I had set up before. - I booted the primary root - I rsycned it to /root2 - I fixed up /root2/etc/fstab to indicate it's proper location - I copied /dev/null to /root2/var/log/messages and /root2/var/log/audit/audit.log so they are zero length - I touched /root2/.autorelabel - I booted the root2 environment. It re-labeled. - I was then unable to log in as I described in this bug. - I booted the primary root again, and copied over the messages and audit.log to attach to this bug. So audit.log and messages represent a single boot of the rsynced root environment. During that boot, the relabel would have happened, startup occurred, then I was unable to log in as root due to permission denied on my shell. Same with ssh. I hope this has the information you need. Thank you.
Looks like login/init/initrc_exec_t are not labeled correctly. login is running as kernel_t, which means a transition never happened. When kernel_t runs /sbin/init (init_exec_t) it should transition to init_t, which eventually runs getty and login and should run those transitions. I Believe you still have a labeling problem.
Is there some other information you need from me? I'd be happy to try a new test with a newer version of the development distro. I really only did the base install for this test. So the state of the system is the state the installer left it in. I'm no expert on this stuff though. Just let me know if you'd like me to do a new test. -Erik
So this looks like autorelabel is happening after the login process is already started??? Maybe we should check the file context on the /sbin/init If it is wrong before the relabel, then we need to reboot after relabeling. Dan
We are making this change in the next version of initscripts.
This should already be fixed in 8.16-1.