When doing a new fresh install on a ppc machine with all the latested updated packages, (ie with all updates spun into the install tree), the resulting install has some odd selinux issues. root ends up with: root seems to get uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=system_u:system_r:hotplug_t:s0-s0:c0.c1023 which doesn't allow root to login at all. type=AVC msg=audit(1209955458.284:14): avc: denied { entrypoint } for pid=2199 comm="gdm-binary" path="/usr/bin/gnome-keyring-daemon" dev=hda4 ino=6486205 scontext=system_u:system_r:hotplug_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=file type=AVC msg=audit(1209955458.794:17): avc: denied { entrypoint } for pid=2201 comm="gdm-binary" path="/etc/X11/xinit/Xsession" dev=hda4 ino=1865418 scontext=system_u:system_r:hotplug_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=file I see in install.log: Installing selinux-policy-targeted - 3.0.8-98.fc8.noarch /usr/sbin/semanage: range not supported on Non MLS machines /usr/sbin/semanage: Invalid prefix guest /usr/sbin/semanage: Invalid prefix xguest Note that this doesn't happen on x86 installs... ;( Note further that a normal f8 stock install, then updated to the latest via yum works fine, it's only a fresh install with the latest that causes the issue. Also, a 'touch /.autorelabel; reboot' fixes it...
Although caused by the latest Fedora Unity Re-Spin - and as such not by any means RH/FP's responsibility, this pretty much sums up what things need to be enhanced for, like being discussed at the SELinux mailing list @rh.c
Thread at https://www.redhat.com/archives/fedora-selinux-list/2008-April/msg00047.html
This looks like the kernel was not built with MLS turned on. Is there a chance the ppc kernel was built differently then the x86? I don't see how this relates to the other problem. The AVC you have aove indicates /etc/X11/xinit/Xsession was not labeled on install. (file_t). Is this a file moved from some other location? The semanage commands that are failing indicates that you have a kernel that does not support MLS/MCS Labeles but policy was built with this support.
Daniel, the installation media he used was composed with SELinux in enforcing mode, which will end up with the policies not being available during the installation -although available in RPM form, the installer runs without SELinux and can therefore apply the right context to files it installs, and hence once done installing wrong labels are all over the place.
OK there has been some movement on this for the kernel, once we have the kernel in place that allows rpm to put down the correct contexts, we can trick selinux-policy rpm to do the right thing.
ok, so I guess we can close this bug off? and wait for progress on other fronts? Thanks for explaining what was going on Jeroen...