On recent install tests I've noticed that I couldn't log in to the installed system as root without booting with 'enforcing=0'. It seems like, post-install, large swathes of the system are mislabelled. Running "restorecon -nvr / | wc -l" after a minimal install reports 25675 - i.e. 25675 files are mislabelled. Proposing as an Alpha blocker: this is a violation of "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." - https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria#Expected_installed_system_boot_behavior - as you can't log in to a minimal install without setting SELinux to permissive.
Sorry, I should specify, this is after a boot.iso install.
bcl says anaconda didn't change anything, so CCing mgrepl and dwalsh.
So, this is another consequence of the change in libselinux 2.3-10: "- is_selinux_enabled: Add /etc/selinux/config test (#1219045)" That is, in response to https://bugzilla.redhat.com/show_bug.cgi?id=1219045 , is_selinux_enabled() was changed to only succeed if /etc/selinux/config existed. It does not exist in the anaconda environment, so in the anaconda environment is_selinux_enabled() fails. This (I don't know precisely how and I'm not digging into the dnf/rpm/libselinux interactions to find out :>) results in default contexts not being set for anything, it seems. I built a libselinux with that change reverted and applied it as an updates.img, and the installed system was no longer completely mislabelled (a few files still are mislabelled - some kernel files in /boot and /usr/lib/modules , and some stuff in /tmp and /sys that would get recreated on boot anyway). So to fix this either libselinux needs to change is_selinux_enabled() yet again somehow, or we need to add a /etc/selinux/config to the anaconda environment.
/etc/selinux/config is part of the selinux-policy package and lorax dumps that in runtime-cleanup.tmpl: removepkg checkpolicy selinux-policy libselinux-utils so to keep /etc/selinux/config in the anaconda env we'd have to tweak that. re-assigning to lorax for now, if we decide it's libselinux that should change we can re-assign again.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
From the point of view of libselinux, SELinux is enabled when a system runs with SELinux enabled kernel. There used to be a check if a policy is loaded but it was considered as a hack and it caused some deadlocks in X.org. There's another bug [1] assigned to anaconda where it's suggested to copy /etc/selinux/config file from a ramdisk to a filesystem as soon as possible. The check of existence of /etc/selinux/config is just a fix to suppress regressions on misconfigured systems with SELinux enabled kernel but without any SELinux policy. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1229788
The bug report you mention is basically irrelevant in this case because the issue here is not /etc/selinux/config missing in the *installed system root*, but it mssing from the *installer environment*. That's why the result in F23 is much worse than in F22.
Discussed at today's blocker review meeting [1]. This bug was accepted as Alpha blocker - This bug is a clear violation of the following criteria: "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] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-07-20/
(In reply to Adam Williamson from comment #7) > The bug report you mention is basically irrelevant in this case because the > issue here is not /etc/selinux/config missing in the *installed system > root*, but it mssing from the *installer environment*. That's why the result > in F23 is much worse than in F22. Not sure if I understand correctly. The problem is with removepkg checkpolicy selinux-policy libselinux-utils which means /ect/selinuc/config is missing.
Yes, that's what's happening in F23. The other bug you refer to is for F22, and what happens there is different. The F22 installer environment doesn't have /etc/selinux/config either - but it also doesn't have the updated libselinux, so for processes running in the context of the installer environment, SELinux is considered 'active'. The installed system root, however, *does* get the updated libselinux (if the update repos are available). It seems like some or all scriptlets run in the context of the installed system, so it's files created by scriptlets that get mislabelled, for those packages installed after libselinux but before selinux-policy. That's how I read it, anyway. There's already a fix posted for this: https://lists.fedorahosted.org/pipermail/anaconda-patches/2015-July/021371.html
This was fixed by lorax-23.14-1.fc23 .