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
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
