SSHD and SELinux entrypoint access denied
Description of problem:
Upon system bootup, everything is fine and no issue occur. However as root, restart the sshd and then the users ssh connection is presented with :
@####'s password:
Last login: Fri Feb 7 14:36:55 UTC 2014 from ### on pts/1
Last login: Fri Feb 7 14:38:37 2014 from ###
/bin/bash: Permission denied
Connection to #### closed.
Selinux shows this in the logs:
type=AVC msg=audit(1391783451.309:99): avc: denied { entrypoint } for pid=3461 comm="sshd" path="/bin/bash" dev=dm-0 ino=4774818 scontext=user_u:system_r:update_modules_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=AVC msg=audit(1391783815.832:111): avc: denied { entrypoint } for pid=3489 comm="sshd" path="/bin/bash" dev=dm-0 ino=4774818 scontext=user_u:system_r:update_modules_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
type=AVC msg=audit(1391783917.334:125): avc: denied { entrypoint } for pid=3527 comm="sshd" path="/bin/bash" dev=dm-0 ino=4774818 scontext=user_u:system_r:update_modules_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
setroubleshoot: SELinux is preventing sshd (update_modules_t) "entrypoint" to /bin/bash (shell_exec_t). For complete SELinux messages. run sealert -l b134f048-ea68-41c1-a35e-6c1dd6f18c44
sealert -l b134f048-ea68-41c1-a35e-6c1dd6f18c44
Summary:
SELinux is preventing sshd (update_modules_t) "entrypoint" to /bin/bash
(shell_exec_t).
Detailed Description:
SELinux denied access requested by sshd. It is not expected that this access is
required by sshd and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for /bin/bash,
restorecon -v '/bin/bash'
If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Context user_u:system_r:update_modules_t
Target Context system_u:object_r:shell_exec_t
Target Objects /bin/bash [ file ]
Source sshd
Source Path /usr/sbin/sshd
Port
Host hal04.halogenonline.co.uk
Source RPM Packages openssh-server-4.3p2-82.el5
Target RPM Packages bash-3.2-32.el5_9.1
Policy RPM selinux-policy-2.4.6-346.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall_file
Host Name hal04.halogenonline.co.uk
Platform Linux hal04.halogenonline.co.uk 2.6.18-371.3.1.el5
#1 SMP Mon Nov 11 03:24:35 EST 2013 i686 i686
Alert Count 29
First Seen Wed Feb 5 15:53:59 2014
Last Seen Fri Feb 7 12:20:43 2014
Local ID b134f048-ea68-41c1-a35e-6c1dd6f18c44
Line Numbers
Raw Audit Messages
host=hal04.halogenonline.co.uk type=AVC msg=audit(1391775643.42:73): avc: denied { entrypoint } for pid=3333 comm="sshd" path="/bin/bash" dev=dm-0 ino=4774818 scontext=user_u:system_r:update_modules_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file
host=hal04.halogenonline.co.uk type=SYSCALL msg=audit(1391775643.42:73): arch=40000003 syscall=11 success=no exit=-13 a0=8476868 a1=bf7ff828 a2=847cef8 a3=0 items=0 ppid=3332 pid=3333 auid=503 uid=503 gid=503 euid=503 suid=503 fsuid=503 egid=503 sgid=503 fsgid=503 tty=pts1 ses=5 comm="sshd" exe="/usr/sbin/sshd" subj=user_u:sysadm_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Version-Release number of selected component (if applicable):
openssh-server-4.3p2-82.el5
libselinux-devel-1.33.4-5.7.el5
selinux-policy-targeted-2.4.6-346.el5
libselinux-1.33.4-5.7.el5
selinux-policy-2.4.6-346.el5
selinux-policy-minimum-2.4.6-346.el5
libselinux-utils-1.33.4-5.7.el5
libselinux-python-1.33.4-5.7.el5
Feb 7 14:30:51 hal04 setroubleshoot: SELinux is preventing sshd (update_modules_t) "entrypoint" to /bin/bash (shell_exec_t). For complete SELinux messages. run sealert -l c65c8e44-d025-477f-aec1-64429b734f62
Feb 7 14:36:55 hal04 setroubleshoot: SELinux is preventing sshd (update_modules_t) "entrypoint" to /bin/bash (shell_exec_t). For complete SELinux messages. run sealert -l c65c8e44-d025-477f-aec1-64429b734f62
Feb 7 14:38:37 hal04 setroubleshoot: SELinux is preventing sshd (update_modules_t) "entrypoint" to /bin/bash (shell_exec_t). For complete SELinux messages. run sealert -l c65c8e44-d025-477f-aec1-64429b734f62
How reproducible:
Steps to Reproduce:
1. Run RHEL 5 system
2. restart sshd
3. try to ssh to system
Actual results:
selinux blocks entrypoint
Expected results:
selinux should allow entrypoint
Additional info:
Two systems build using simuarl kickstarts occour with this issue.
System reboot will restore sshd connectivity as well as setenforce 0.
System with selinux enforcing on bootup will allow ssh connection.
https://bugzilla.redhat.com/show_bug.cgi?id=1062643
Responses
Hi Matt,
EDITED: Several suggestions posted over several days, please see all the posts. I know, it is a long shot. I deal also with several MLS SE Linux systems and hope some of what I posted might be a work-around since it is likely no fix is in the immediate future...
Regards...
MLS SELinux - fun, we have some of those... Since this bit you posted is a bugzilla, this bit below likely won't do anything.. but just a few thoughts.
I checked out the bugzilla. Do you have any users at all or other rhel 5.x MLS SELinux systems where you can ssh into the system successfully? I suspect not.
Also, I noticed from your output above, is some of that output the result of running the:
run sealert -l c65c8e44-d025-477f-aec1-64429b734f62
When you created the users, did you create any with other roles in your MLS SELinux instantiation and do they experience the same issue?
Do you have any other MLS SELinux systems or users with different roles where this does work? (such as staff_r, user_r, sysadm_r or whatever you defined)?
- Perhaps the default role of the affected user could be changed so that it's role could access /bin/bash after an ssh... (I can see why you put in a bugzilla)
What 'semanage login' (or if you need to , try "semanage login --modify" to change it if needed) command did you use for the user to instantiate roles etc for the user after their account was made? - is there a difference for that user than the others (if another user's account functions)?
semanage login -l
Have you tried an strace during the login process (if possible?, may have to be in a similar role, MLS may shield output based on roles).
that sealert command from above might help shed some light but since this is a bugzilla... Perhaps examine this RH info
What happens if someone with that account logs in locally, that is log in locally then do an ssh nameofuser@nameofsystem? and then perhaps run the strace etc... Does the ssh function properly for any other user?
Since this is a bugzilla, the above probably won't help.
Matt,
I know this is a bugzilla...
Since it looks like they will not currently fix it,
Any chance you could try such an MLS SELinux system using the most current version of rhel 6 and see if it works there (even in a lab)... I imagine you might have to get the system approved via management or security channels.
Matt,
One other potential ugly work-around... (given the bugzilla says it won't be fixed with 5.11)
- Change the default shell for the affected user to another shell in /etc/passwd (i.e. csh, tcsh) and see if the problem continues.
* I wonder if you'd have to do a 'semanage login --modify [args] ' afterwards if the default shell were changed...
- Not that it would help - how about an ssh key? I'd try that, but would bank on it not working, but try it anyway. see post further down for a bit from Dan Walsh and labels for home and ssh keys (scroll down)
Matt,
I recognize you have a bugzilla in, and these are likely long shots. Perhaps is worth a shot to check.
- Have you tried using ssh with that non-root user to a different autorized context? (granted the example is for rhel6, but according to this link, people have been using similar methods with lower versions of RHEL with MLS SELinux.
(assuming the "staff_r" below is another existing role for that user if possible)
[mlsuser@rhel6 ~]$ ssh mlsuser/staff_r/C-TS@localhost
[mlsuser@rhel5 ~]$ ssh -l mlsuser/staff_r localhost
Here and here show a person having a problem with ssh with MLS SELinux and Dan Walsh wrote back to change pam_selinux
this video (part 8 of 9) at Red Hat by Dave Egts (Sr Architect with Red Hat) has to do with MLS SELinux on RHEL 6, however, may shed some light on the conundrum you are facing with ssh with a specific user.
In just over 3 minutes in the video, it shows (this is for rhel 6, have not tried this on rhel 5) that you can ssh in at a particular sensitivity within your user's allowable range. Here is the associated pdf for this is also at this link (rhel 6 MLS SELinux)
Matt, I realize you have a bugzilla in, but (yes probably a long shot), did you check out allow2audit?
(See slide 53 from Dan Walsh' MLS SELinux
- rhel 5 allow2audit some instructions here
- Tool that generates policy allow rules from logs of denied operations.
- rhel 5 audit2why
- Translates SELinux audit messages into a description of why the access was denied. (yes, in the bugzilla)
- Lastly, if you are using ssh keys for that user, see this bit from Dan Walsh in an older post he made regarding the differences between user_home_dir_t and user_home_t with ssh keys etc.
Thanks David,
I posted something at the bugzilla for this - the suggestions I provided may not help, but it's worth chasing just in case.
Also noticed this today https://access.redhat.com/site/solutions/755063 although that article seems to be for targed SELinux and not MLS SELinux.
Hi Matt,
Glad you checked in on this discussion.
Was it your intention to have this system you describe to be an MLS system? (especially see step 2 of this link in this paragraph if you do want it to be an MLS SELinux system)
I noticed in your original post this bit below (and note you have 'targeted' in /etc/selinux/config file):
MLS Enabled True
See the other comments I mentioned previously, along with the links I posted.
Kind Regards,
Remmele
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
