0

I'm trying to set up sshd to run under xinetd on an RHEL7 server. I run sshd on an alternate port, using xinetd to limit what IPs can connect.

This works fine on RHEL6, and also on RHEL7 if I disable SELinux. However, the targeted SELinux policy on RHEL7 is preventing it.

Unfortunately, it's not logging much useful in /var/log/audit when it fails. My connection attempt yields two lines of successful CRYPTO_KEY_USER operations, and then this (a single line, which I've wrapped):

type=USER_LOGIN msg=audit(1485378997.248:18523): pid=6812 uid=0 
auid=4294967295 ses=4294967295 
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=login acct="(unknown)" exe="/usr/sbin/sshd" 
hostname=? addr=A.B.C.D terminal=ssh res=failed'

audit2why doesn't even acknowledge that a problem exists. I'd guess it is looking for DENY events or something like that, not failures.

I added debug logging to sshd and found this (not wrapped this time):

debug1: SELinux support enabled [preauth]
debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:system_r:sshd_net_t:s0-s0:c0.c1023' [preauth]
debug3: privsep user:group 74:74 [preauth]
debug1: permanently_set_uid: 74/74 [preauth]
debug1: list_hostkey_types: ssh-rsa [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
Write failed: Permission denied [preauth]

I presume this is my problem - the transition from sshd_t to sshd_net_t. However, without any useful information from the audit logs, I've reached the limit of my SElinux debugging skills.

A colleague suggested I review the audit logs from a successful connection in permissive mode. Unfortunately, there's no mention of a successful action as sshd_net_t. Here are the relevant log entries: http://pastebin.com/raw/9sSVpgLq

I did see some relevant information on the redhat bug tracker, but it didn't get me very far toward a solution. https://bugzilla.redhat.com/show_bug.cgi?id=1008580

  • Is this even supported anymore? It wasn't a very good idea to begin with. And besides, you can set up a firewall zone to do this, and then you can just run sshd normally. – Michael Hampton Jan 25 '17 at 23:04
  • Ahhh....SELinux is actively supported and there are many people working with Linux systems. In Linux systems operating in the government (esp military constabulary) enforcing mode is a requirement. – mdpc Jan 26 '17 at 1:09
  • Michael is probably asking about running ssh as a xinetd service, not SELinux. Can you elaborate on the use case for using SSH as a xinetd service? – dawud Jan 26 '17 at 11:03
  • systemd does not provide the ability to limit what IPs can connect to a service; xinetd does. You are right that iptables/firewalld can restrict access to the port; we prefer to use both methods in concert. 0pointer.de/blog/projects/inetd.html "That said, there are a couple of useful features that systemd does not support, for example IP ACL management." That blog entry also mentions something about tcpwrap support, which i guess i will investigate. Regardless, I'm really curious about this problem. – Dan Pritts Jan 26 '17 at 14:39
  • Xinetd has no place in this chain. Why make this more difficult? Are there requirements that you're not articulating in the question? – ewwhite Jan 26 '17 at 14:59
0

It turns out that certain SELinux rules are not audited by default. Running:

semanage dontaudit off

enables audit logging even on "dontaudit" rules in the policy.

Once I did that, it was easy to track down the missing SELinux permissions (which were allow sshd_net_t inetd_t:tcp_socket (read|write);).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.