Created attachment 914746 [details] audit.log.bz2 Description of problem: I was presented with standard shell login screen. I entered my root credentials, hit enter, screen flashed and I was back on login screen. Tried this a couple of times and result was always the same. This was happening with selinux in enforcing mode. (Eventually I could log in with init=/bin/bash on kernel command line, then I disabled SELinux and I was able to log in properly.) Version-Release number of selected component (if applicable): selinux-policy-3.13.1-62.fc21.noarch How reproducible: 100 % Steps to Reproduce: 1. Install fresh rawhide (I did that on 2014-07-04) 2. Try to log-in to text console Actual results: Access to /usr/bin/bash is denied. Additional info: I'm going to attach audit.log. This part is probably the most interesting: type=CRED_REFR msg=audit(1404489277.629:84): pid=745 uid=0 auid=0 ses=2 subj=system_u:system_r:kernel_t:s0 msg='op=PAM:setcred acct="root" exe="/usr/bin/login" hostname=? a ddr=? terminal=tty1 res=success' type=USER_LOGIN msg=audit(1404489277.630:85): pid=745 uid=0 auid=0 ses=2 subj=system_u:system_r:kernel_t:s0 msg='op=login id=0 exe="/usr/bin/login" hostname=? addr=? termin al=tty1 res=success' type=AVC msg=audit(1404489277.637:86): avc: denied { transition } for pid=838 comm="login" path="/usr/bin/bash" dev="dm-1" ino=4208 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=0
Myself, satellit and xmrbrz from #fedora-qa all also saw this issue. It affects regular user accounts as well as root, and both console and graphical logins. Login works successfully when booted with 'enforcing=0'. Updating to selinux-policy-targeted 3.13.1-63.fc21 does not help. I did a default network install from 2014-07-04 x86_64 boot.iso to a KVM. Logs don't seem terribly helpful, but I'll attach one shortly for reference. Nominating as an Alpha blocker, violates "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." - https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_installed_system_boot_behavior .
Created attachment 914796 [details] journal of an affected boot. booted at 17:06, attempted to log in graphically at 17:07, attempted to log in via console at 17:08, rebooted at 17:09
Did you try to fix labeling on your system? The problem is we see kernel_t.
Could you be more specific, please? What should I try? I did clean installation so I didn't feel necessity of 'fixing' anything, it should just work :-) I can give you access to VM console if you want to look into it yourself.
(In reply to Petr Spacek from comment #4) > Could you be more specific, please? What should I try? > > I did clean installation so I didn't feel necessity of 'fixing' anything, it > should just work :-) Yes it should. But maybe there is a bug. >I can give you access to VM console if you want to look > into it yourself. It would be great.
The problem is we have lrwxrwxrwx. root root system_u:object_r:root_t:s0 sbin -> /usr/sbin .. .. dr-xr-xr-x. root root system_u:object_r:root_t:s0 bin drwxr-xr-x. root root system_u:object_r:root_t:s0 games drwxr-xr-x. root root system_u:object_r:root_t:s0 include dr-xr-xr-x. root root system_u:object_r:root_t:s0 lib dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib64 drwxr-xr-x. root root system_u:object_r:root_t:s0 libexec drwxr-xr-x. root root system_u:object_r:root_t:s0 local dr-xr-xr-x. root root system_u:object_r:root_t:s0 sbin drwxr-xr-x. root root system_u:object_r:root_t:s0 share drwxr-xr-x. root root system_u:object_r:root_t:s0 src lrwxrwxrwx. root root system_u:object_r:root_t:s0 tmp -> ../var/tmp
Adam, do you have the same labeling issue?
I logged with enforcing=0 (boot parameter) and used the "setenforce 1" command before you list the permissions of context, if it is correct, these are my results: [root@localhost /]# ls -Z / lrwxrwxrwx. root root system_u:object_r:root_t:s0 sbin -> usr/sbin [...] [root@localhost /]# ls -Z /usr/ dr-xr-xr-x. root root system_u:object_r:root_t:s0 bin drwxr-xr-x. root root system_u:object_r:root_t:s0 games drwxr-xr-x. root root system_u:object_r:root_t:s0 include dr-xr-xr-x. root root system_u:object_r:root_t:s0 lib dr-xr-xr-x. root root system_u:object_r:lib_t:s0 lib64 drwxr-xr-x. root root system_u:object_r:root_t:s0 libexec drwxr-xr-x. root root system_u:object_r:root_t:s0 local dr-xr-xr-x. root root system_u:object_r:root_t:s0 sbin drwxr-xr-x. root root system_u:object_r:root_t:s0 share drwxr-xr-x. root root system_u:object_r:root_t:s0 src lrwxrwxrwx. root root system_u:object_r:root_t:s0 tmp -> ../var/tmp
Discussed at the 2014-07-09 Fedora 21 alpha blocker review meeting. Accepted as a blocker for Fedora 21 alpha due to violation of the following alpha release criteria [1]: A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility. A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles. [1] https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
the filesystem package has not changed since March 2014, and I don't quite understand what it is you're saying is wrong. You said "the problem is we have" and then posted a directory listing, but didn't unpack beyond that: what element of that directory listing is the problem, and are we sure it's caused by filesystem? If so, why did this break now and not in March? Thanks!
Ah, I wanted to move it to anaconda. The problem is we end up with root_t labeling for "sbin" and "bin" top level symlinks. So we need to find out who places these symlinks.
'enforcing=0' required for f21 20140710 live soas x86_64 spin in VirtualBox to start. liveinst from terminal boots VirtualBox HD install without requiring 'enforcing=0'
and presumably the correct labelling is what I have on my previously-installed system: [adamw@adam ~]$ ls -lZ /*bin lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /bin -> usr/bin lrwxrwxrwx. root root system_u:object_r:bin_t:s0 /sbin -> usr/sbin [adamw@adam ~]$ ls -ldZ /usr/*bin dr-xr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin dr-xr-xr-x. root root system_u:object_r:bin_t:s0 /usr/sbin right? actually, it seems like the labelling of several of the other directories at the top level and in /usr is wrong, compared to my existing installed system. I'll try and do a bit of triage on this using older boot.iso images and hopefully live images, if I can find some that install - at least then we can get an idea whether the breakage is in anaconda, or some package that's part of the installed system, or what.
*** Bug 1118192 has been marked as a duplicate of this bug. ***
I just did one test at least which points to anaconda (or the installer environment, at least). I did an install from an older known-good boot.iso I keep around, from 2014-05-12. That's a network install, so it installed a completely contemporary package set - selinux-policy-targeted-3.13.1-63.fc21 , for instance, and kernel 3.16.0-0.rc4.git2.1.fc21 . But I can log into the installed system successfully, and the labels on /bin and /sbin are correct (bin_t). so, this at least indicates it's not the packages getting installed, but something the installer's doing or something in the installer environment that broke. in any case, it's definitely not filesystem, so i'm gonna punt it to anaconda for now. I'll compare install logs from the 2014-05-12 install and a buggy install with recent boot.iso and see if anything looks different.
OK, comparing logs from a 2014-05-12 boot.iso install with a 2014-07-10 boot.iso install (obviously, I confirmed the 2014-05-12 install is not affected by the bug, the 2014-07-10 install is affected by it), I see one possibly significant difference in the journal output. 20140710 has this, which 20140512 does not have, during selinux initialization: Jul 10 22:58:25 localhost kernel: SELinux: Permission audit_read in class capability2 not defined in policy. Jul 10 22:58:25 localhost kernel: SELinux: the above unknown classes and permissions will be allowed That's the only thing that leaps out at me, but the logs are long and I'm not sure what I'm looking for exactly. I'll attach both.
Created attachment 917206 [details] journal.log from 2014-05-12 (unaffected) installation
Created attachment 917207 [details] journal.log from 2014-07-10 (affected) installation
I ran into this using a boot.iso from last week, relabeling the system fixed it so I think we just need to wait for an updated boot.iso
*** Bug 1052317 has been marked as a duplicate of this bug. ***
The problem is the labels are placed wrongly by a tool during install/upgrade phase.
So I don't see it as selinux-policy issue.
anaconda devs are saying there is no 'tool' that sets labels during install/upgrade phase. presumably it gets done by selinux *somehow*. all anaconda does is install packages.
That comment from anaconda is incorrect, see 80-setfilecons.ks. However, I doubt it's the source of this bug.
Here's what /mnt/sysimage looks like during (and after) an install from a boot.iso created on 7/11: lrwxrwxrwx. root root system_u:object_r:root_t:s0 bin -> usr/bin dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot drwxr-xr-x. root root system_u:object_r:device_t:s0 dev drwxr-xr-x. root root system_u:object_r:root_t:s0 etc drwxr-xr-x. root root system_u:object_r:root_t:s0 home lrwxrwxrwx. root root system_u:object_r:root_t:s0 lib -> usr/lib lrwxrwxrwx. root root system_u:object_r:lib_t:s0 lib64 -> usr/lib64 drwx------. root root system_u:object_r:lost_found_t:s0 lost+found drwxr-xr-x. root root system_u:object_r:root_t:s0 media drwxr-xr-x. root root system_u:object_r:root_t:s0 mnt drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt dr-xr-xr-x. root root system_u:object_r:proc_t:s0 proc dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root drwxr-xr-x. root root system_u:object_r:var_run_t:s0 run lrwxrwxrwx. root root system_u:object_r:root_t:s0 sbin -> usr/sbin -rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 selinux-root-sysimage.txt drwxr-xr-x. root root system_u:object_r:var_t:s0 srv dr-xr-xr-x. root root system_u:object_r:sysfs_t:s0 sys drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp drwxr-xr-x. root root system_u:object_r:root_t:s0 usr drwxr-xr-x. root root system_u:object_r:root_t:s0 var A number of these are clearly labeled wrong. filesystem owns these but some are created before filesystem is installed (the package ordering for this installation was libgcc, fedora-release, fedora-repos-rawhide, fedora-repos, setup, filesystem, ...) A boot.iso from 06/27 works correctly. The labels are initially root_t but after about 10 packages are installed they switch to their correct values (about the time basesystem is installed). filesystem and basesystem have not changed in that time period so I'm fairly sure this is a selinux change causing this.
I wonder if this is actually fallout from http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=713914bde185393003b6a5fd1a229ebffd1fa784 The thing is of course when installing a pile of RPMs, since selinux-policy is itself an RPM[1], there's no policy loaded into the transaction until we get to that package. I'm pretty sure the way it worked before was that sepolicy plugin was calling restorecon -R / in the install root. But now we no longer have a plugin. (BTW, this bug doesn't affect OSTree installs because we do SELinux labeling in a much more hardcoded, direct, and reliable fashion)
(In reply to satellit from comment #12) > 'enforcing=0' required for f21 20140710 live soas x86_64 spin in VirtualBox > to start. > liveinst from terminal boots VirtualBox HD install without requiring > 'enforcing=0' I have not been able to repeat this on bare metal or in later Virtual Box installs
Anaconda is supposed to have an selinux-policy in its build root that allows rpm to do proper labeling when content gets installed. This looks like early part of install is screwed up, Or these file/directories get created by anaconda and not rpm, which means they would get created with the wrong label. We could setup a group of filename transitions for the directories created in / which would create them with the correct label.
Colin: "That comment from anaconda is incorrect" Please blame it on me, not them - I was paraphrasing from IRC notes, probably incorrectly. Apologies.
(In reply to Daniel Walsh from comment #28) > Anaconda is supposed to have an selinux-policy in its build root that allows > rpm to do proper labeling when content gets installed. This looks like > early part of install is screwed up, Or these file/directories get created > by anaconda and not rpm, which means they would get created with the wrong > label. We could setup a group of filename transitions for the directories > created in / which would create them with the correct label. It looks like they are created by yum or rpm at the start of the transaction -- at least I see them show up after anaconda-yum is started, but before any actual packages have been reported as being installed. I built a 2nd boot.iso today using selinux-3.13.1-62 to see if that would fix the problem, and it doesn't. So I'm stumped as to what's going on here.
Ends up this was a combination of rpm splitting out selinux into a plugin and lorax removing too much from rpm when trimming down the boot.iso
confirming this is fixed with a 2014-07-17 nightly F21 boot.iso. closing.