-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Jaegermann wrote: > On Mon, Dec 29, 2008 at 10:30:31AM -0500, Daniel J Walsh wrote: >> Michal Jaegermann wrote: >>> I wonder if this is my unique experience or this is widely observed. >>> >>> So far, AFAICT, when installing a machine "from scratch", and while >>> keeping a layout as plain as possible, then selinux is rather >>> expected to work; at least decently enough. The picture becomes >>> entirely diferent when you are trying to upgrade a distro. What >>> results of such exercise will be I am unable to predict. > .... >> Ok lets look at the log file. >> >> This works but I am getting every >>> time "Unable to get valid context for root" and in /var/log/secure: >>> "pam_selinux(sshd:session): Security context >>> system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for >>> system_u:system_r:logrotate_t:s0-s0:c0.c1023". >> When you log in in permissive mode what does 'id -Z' show? > > Something rather weird for 'id -Z': system_u:system_r:system_crond_t:s0 > The other machine after an upgrades reports > 'root:unconfined_r:unconfined_t:SystemLow-SystemHigh' which looks > like something saner. > >> # semanage login -l > > Login Name SELinux User MLS/MCS Range > > __default__ unconfined_u s0-s0:c0.c1023 > root system_u s0-s0:c0.c1023 > system_u system_u s0-s0:c0.c1023 > > which again is different than on another machine. Here we go: > > Login Name SELinux User MLS/MCS Range > > __default__ unconfined_u SystemLow-SystemHigh > root root SystemLow-SystemHigh > system_u system_u SystemLow-SystemHigh > >> and >> # semanage user -l > > > Labeling MLS/ MLS/ > SELinux User Prefix MCS Level MCS Range SELinux Roles > > guest_u guest s0 s0 guest_r > root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r > staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r > sysadm_u user s0 s0-s0:c0.c1023 sysadm_r > system_u user s0 s0-s0:c0.c1023 system_r > unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r > user_u user s0 s0 user_r > xguest_u xguest s0 s0 xguest_r > > and this is on that second one: > > Labeling MLS/ MLS/ > SELinux User Prefix MCS Level MCS Range SELinux Roles > > guest_u user s0 s0 guest_r > root user s0 SystemLow-SystemHigh staff_r sysadm_r system_r unconfined_r > staff_u user s0 SystemLow-SystemHigh staff_r sysadm_r system_r > sysadm_u user s0 SystemLow-SystemHigh sysadm_r > system_u user s0 SystemLow-SystemHigh system_r > unconfined_u user s0 SystemLow-SystemHigh system_r unconfined_r > user_u user s0 s0 user_r > xguest_u user s0 s0 xguest_r > > where at least "Labeling Prefixes" look suspicious for a change. > >> Finally what context is ssh running as. >> >> # ps -eZ | grep ssh > > system_u:system_r:system_crond_t:s0 3972 ? 00:00:00 sshd > system_u:system_r:system_crond_t:s0 26371 ? 00:00:00 sshd > > against > > root:system_r:sshd_t:SystemLow-SystemHigh 10298 ? 00:00:00 sshd > root:system_r:sshd_t:SystemLow-SystemHigh 28760 ? 00:00:00 sshd > > where things appear to work as expected. > > A label on /usr/sbin/sshd itself is system_u:object_r:sshd_exec_t:s0 > in the first case and system_u:object_r:sshd_exec_t, without that > trailing ":s0", in the second one. > > All that fun simply as a result of running anaconda with an upgrade > from F8 to F10; in both cases. I noted already that in the first > case I had to do 'touch /.autorelabel' and reboot before I started > to get anywhere and that was not needed in the second case. > > Differences in a file system layout are are that for the first > machine /, /boot, /usr, /usr/local, /var and /home are separate > file systems while the second box has only /boot and / for > everything (it is a specialized server). > > This is not the first time when selinux starts to act "weird" for me > on an installation after anaconda did its work. Only the other > cases were starting from older distributions and this was for > "scratch" installations in any case so the simplest wasy out was to > dump results and run install again. In the current situation this > is really not a good option and besides I would rather like to > understand what is going on. > > Michal > I think the problem is logging in as root is screwed up. if you execute # semanage login -m -s unconfined_u root This should cause root users to login in as unconfined_t automatically. The sshd running as system_crond_t? Does this happen on reboot? Or was this caused by logging in in permissive mode then restarting sshd? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklg7PkACgkQrlYvE4MpobOm1gCePTXfavOEEcTy3DSam/IkvbqV Ch0An1ZlgRAtttd79UlI+U94R59TXI59 =D8Yt -----END PGP SIGNATURE----- -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
