Re: MCS error

[Tracy Reed <treed@ultraviolet.org>]

[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]

On Thu, Feb 19, 2015 at 04:34:25PM PST, Tracy Reed spake thusly:
> # semanage login -l

Ok, part of my confusion here is that I've been confusing semanage login with
semanage user. It's been a while since I've dealt with SELinux. I understand
that semanage login -l shows what Linux users map to what selinux users:

> Login Name                SELinux User              MLS/MCS Range            
> 
> __default__               unconfined_u              SystemLow-SystemHigh     
> p16001                    p16001_u                  p16001                   
> p16002                    appuser_u                 s0:c1.c499-s0:c2         
> p16003                    appuser_u                 s0:c1.c499-s0:c3         
> p16004                    unconfined_u              s0-s0:c0.c1023,c4        
> p16005                    unconfined_u              s0-s0:c0.c1023,c4,c5     
> p16006                    unconfined_u              s0-s0:c0.c1023,c6        
> p16007                    unconfined_u              s0-s0:c0.c1023,c7        
> p16008                    unconfined_u              s0-s0:c0.c1023,c8        
> p16009                    unconfined_u              s0-s0:c0.c1023,c9        
> root                      unconfined_u              SystemLow-SystemHigh     
> system_u                  system_u                  SystemLow-SystemHigh  

So we are mapping p16002 to appuser_u but appuser_u doesn't exist at the
moment. But what's with the MLS/MCS range column?  Is this saying p16002 has
categories s0:c1.c499-s0:c2 is it saying appuser_u (selinux user) has
categories s0:c1.c499-s0:c2? Given that the selinux user is the same but the
categories listed are different for Linux login users p16002 and p16003 I would
think it is saying those categories go with those Linux login users.

How/why is it different from the output of semange user -l ?

# semanage user -l

Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

git_shell_u     user       SystemLow  SystemLow                      git_shell_r
guest_u         user       SystemLow  SystemLow                      guest_r
p16001_u        user       SystemLow  p16001                         user_r
p16002_u        user       SystemLow  p16002                         user_r
root            user       SystemLow  SystemLow-SystemHigh           staff_r sysadm_r system_r unconfined_r
staff_u         user       SystemLow  SystemLow-SystemHigh           staff_r sysadm_r system_r unconfined_r
sysadm_u        user       SystemLow  SystemLow-SystemHigh           sysadm_r
system_u        user       SystemLow  SystemLow-SystemHigh           system_r unconfined_r
unconfined_u    user       SystemLow  SystemLow-SystemHigh           system_r unconfined_r
user_u          user       SystemLow  SystemLow-SystemHigh           user_r
xguest_u        user       SystemLow  SystemLow                      xguest_r

Here there are no Linux users involved, only selinux users it seems, which is
fine. But it shows p16001_u with range  p16001 and p16002_u with p16002.

And that is different yet with respect to the output of the chcat command:

# chcat -L -l p16001 p16002
p16001: s0:c0.c1023
p16002: s0:c0.c1023

This says p16001 and p16002 have access to all categories.

So...who is right?

Also, I'm still trying to figure out how to dig myself out of this hole:

# semanage user -a -R user_r appuser_u
libsemanage.validate_handler: selinux user appuser_u does not exist (No such file or directory).
libsemanage.validate_handler: seuser mapping [p16002 -> (appuser_u, s0:c1.c499-s0:c2)] is invalid (No such file or directory).
libsemanage.dbase_llist_iterate: could not iterate over records (No such file or directory).
/usr/sbin/semanage: Could not commit semanage transaction

This would seem to be a paradox or chicken and egg problem.

Ideas? Thanks! :)

-- 
Tracy Reed

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]