selinux adventures/troubles

[Daniel J Walsh]

-----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-----