Normal user below cannot login when SELinux in enforcing mode.



__default__          unconfined_u         s0-s0:c0.c1023       *
normal+user          staff_u              s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

Hi, 

Is this fresh installation of the system? Could you provide steps how you confined the user? 

Thanks,
Lukas.

Hi

It's running oVirt 4.2.  

semanage login -a -s staff_u user confines the user.

Hi

I am getting this same problem with a normal unconfined root user.

This issue was not selected to be included in Red Hat Enterprise Linux 7.7 because it is seen either as low or moderate impact to a small number of use-cases. The next release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

I have no idea what this means.

I am not able to login to an oVirt virtual machine after enabling SELinux.  Shouldn't a policy make this work by default since it's a common thing (logging into a vm over ssh)?

Created attachment 1549113 [details]
alerts reported by sealert after enforcing selinux

Hello,

We support common administration actions for confined users, this case, however, seems to be a result of some other settings changed on the system.

In particular, off this part of the sealert message:

type=AVC msg=audit(1553785028.96:101): avc:  denied  { dyntransition } for  pid=5240 comm="sshd" s
context=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=pr
ocess permissive=1
type=SYSCALL msg=audit(1553785028.96:101): arch=x86_64 syscall=write success=yes exit=ENOMSG a0=7 
a1=55c44c632aa0 a2=2a a3=666e6f636e753a72 items=0 ppid=5232 pid=5240 auid=8877 uid=8877 gid=2017 e
uid=8877 suid=8877 fsuid=8877 egid=2017 sgid=2017 fsgid=2017 tty=(none) ses=1 comm=sshd exe=/usr/s
bin/sshd subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null)

the sshd process seems to be running in the kernel_t domain which is not correct. Are you aware how the system in question got into this state?

The following command ran on the target system:

  $ ps ax -o pid,ppid,fname,context

should show the main sshd process running in sshd_t domain:

19640     1 sshd     system_u:system_r:sshd_t:s0-s0:c0.c1023

This issue was not selected to be included in Red Hat Enterprise Linux 7 because it is seen either as low or moderate impact to a small number of use-cases. The next minor release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

We will now close this issue, but if you believe that it qualifies for the Maintenance Support 1 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.

Hi

This occurred due to yum update from 7.X to latest version.

The fix was restorecon -R / then reboot!