selinux adventures/troubles

[Michal Jaegermann]

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