Bug 1660891 - staff_u users cannot login - /bin/bash: Permission denied
Summary: staff_u users cannot login - /bin/bash: Permission denied
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.6
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-19 14:45 UTC by Douglas Duckworth
Modified: 2019-11-05 14:55 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-13 15:13:17 UTC
Target Upstream Version:


Attachments (Terms of Use)
alerts reported by sealert after enforcing selinux (9.09 KB, text/plain)
2019-03-28 15:01 UTC, Douglas Duckworth
no flags Details

Description Douglas Duckworth 2018-12-19 14:45:29 UTC
Users confined to staff_u cannot login.

Here's an example error:

SELinux is preventing /usr/sbin/sshd from using the transition access on a process.

Additional Information:
Source Context                system_u:system_r:kernel_t:s0
Target Context                unconfined_u:unconfined_r:unconfined_t:s0
Target Objects                /usr/bin/bash [ process ]
Source RPM Packages           util-linux-2.23.2-59.el7.x86_64
Target RPM Packages           bash-4.2.46-31.el7.x86_64
Policy RPM                    selinux-policy-3.13.1-229.el7_6.6.noarch

type=AVC msg=audit(1545228694.881:192): avc:  denied  { transition } for  pid=24580 comm="login" path="/usr/bin/bash" dev="dm-0" ino=16798459 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass =process permissive=0


When trying to login I get:

/bin/bash: Permission denied

Comment 2 Douglas Duckworth 2018-12-19 14:53:04 UTC
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       *

Comment 3 Lukas Vrabec 2019-01-01 15:45:10 UTC
Hi, 

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

Thanks,
Lukas.

Comment 4 Douglas Duckworth 2019-01-09 15:34:00 UTC
Hi

It's running oVirt 4.2.  

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

Comment 5 Douglas Duckworth 2019-01-15 20:57:55 UTC
Hi

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

Comment 6 Zdenek Pytela 2019-02-28 19:27:50 UTC
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.

Comment 7 Douglas Duckworth 2019-03-28 15:00:32 UTC
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)?

Comment 8 Douglas Duckworth 2019-03-28 15:01:51 UTC
Created attachment 1549113 [details]
alerts reported by sealert after enforcing selinux

Comment 9 Zdenek Pytela 2019-04-01 14:08:24 UTC
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

Comment 12 Zdenek Pytela 2019-08-13 15:13:17 UTC
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.

Comment 13 Douglas Duckworth 2019-11-05 14:55:36 UTC
Hi

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

The fix was restorecon -R / then reboot!


Note You need to log in before you can comment on or make changes to this bug.