Bug 1559355 - The machine is accessible through the sshd.socket (tcpd) dispite hosts.deny settings
Summary: The machine is accessible through the sshd.socket (tcpd) dispite hosts.deny s...
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-22 11:33 UTC by Lukas Ruzicka
Modified: 2018-03-23 16:16 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-03-23 16:16:12 UTC


Attachments (Terms of Use)

Description Lukas Ruzicka 2018-03-22 11:33:58 UTC
Description of problem:

The tcp_wrappers should be deprecated and tcpd should be used instead to deal with rules from the /etc/hosts.allow and /etc/hosts.deny files.

I was following the procedure described here http://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers#Migration_to_tcpd to set up the machine for the following test http://fedoraproject.org/wiki/User:Sumantrom/Draft/Testcase_OpenSSH .

I did all the steps and after the settings (prerequisites) were successfully donewere done) I failed in step 7 of the test, because it did not reject the connection. 

Version-Release number of selected component (if applicable):

openssh-7.6p1.7
selinux-policy-3.14.1.14

How reproducible:

Always

Steps to Reproduce:
1. Follow the tests above

Actual results:

Entries in /etc/hosts.* files have no influence on the system.

Expected results:

Entries in those files should work as they did with tcp_wrappers.


Additional info:

Comment 1 Lukas Vrabec 2018-03-22 11:41:38 UTC
Fixed in newer version of selinux-policy package. https://koji.fedoraproject.org/koji/buildinfo?buildID=1061018 I'll create new update soon.

Comment 2 Lukas Ruzicka 2018-03-22 12:10:29 UTC
I have installed the packages from Koji and still have the same issue.

===
Name        : selinux-policy
Version     : 3.14.1
Release     : 16.fc28
Architecture: noarch
Install Date: Čt 22. březen 2018, 13:07:39 CET
Group       : System Environment/Base
Size        : 24429
License     : GPLv2+
Signature   : (none)
Source RPM  : selinux-policy-3.14.1-16.fc28.src.rpm
Build Date  : St 21. březen 2018, 20:11:28 CET
Build Host  : buildvm-aarch64-09.arm.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : %{git0-base}
Bug URL     : https://bugz.fedoraproject.org/selinux-policy
Summary     : SELinux policy configuration
Description :
SELinux Base package for SELinux Reference Policy - modular.
Based off of reference policy: Checked out revision  2.20091117
====

Comment 3 Jakub Jelen 2018-03-23 08:28:10 UTC
Did you enable the `ssh_use_tcpd` SELinux boolean after installing the update? To verify, list the booleans state:

    semanage boolean --list | grep ssh_use_tcpd

Comment 4 Lukas Ruzicka 2018-03-23 09:44:05 UTC
I did not have it enabled, so I have enabled it, and still allows me to log in. I also tried to setenforce to 0, but no difference.

Comment 5 Jakub Jelen 2018-03-23 11:04:45 UTC
Please, make sure that:

 * sshd.service is stopped

    systemctl status sshd.service

 * sshd.socket is enabled and started

    systemctl status sshd.socket

 * sshd@.service is using the modified ExecPath

    systemctl cat sshd@.service

 * systemd daemon is reloaded:

    systemctl daemon-reload

Also attach the output of the above commands.

Comment 6 Lukas Ruzicka 2018-03-23 15:37:34 UTC
(In reply to Jakub Jelen from comment #5)
>  * sshd.service is stopped
-----------------------------------------------
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/sshd.service.d
           └─filter.conf
   Active: inactive (dead) since Fri 2018-03-23 12:57:56 CET; 30min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1321 (code=exited, status=0/SUCCESS)

bře 23 12:43:37 localhost.localdomain systemd[1]: Starting OpenSSH server daemon...
bře 23 12:43:37 localhost.localdomain sshd[1321]: Server listening on 0.0.0.0 port 22.
bře 23 12:43:37 localhost.localdomain sshd[1321]: Server listening on :: port 22.
bře 23 12:43:37 localhost.localdomain systemd[1]: Started OpenSSH server daemon.
bře 23 12:57:56 localhost.localdomain sshd[1321]: Received signal 15; terminating.
bře 23 12:57:56 localhost.localdomain systemd[1]: Stopping OpenSSH server daemon...
bře 23 12:57:56 localhost.localdomain systemd[1]: Stopped OpenSSH server daemon.
---------------------------------------------------
 
* sshd.socket is enabled and started

--------------------------------------------------
● sshd.socket - OpenSSH Server Socket
   Loaded: loaded (/usr/lib/systemd/system/sshd.socket; enabled; vendor preset: disabled)
   Active: active (listening) since Fri 2018-03-23 13:00:56 CET; 28min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
   Listen: [::]:22 (Stream)
 Accepted: 4; Connected: 0
    Tasks: 0 (limit: 2891)
   Memory: 36.0K
   CGroup: /system.slice/sshd.socket

bře 23 13:00:56 localhost.localdomain systemd[1]: Listening on OpenSSH Server Socket.
--------------------------------------------------

* sshd@.service is using the modified ExecPath
--------------------------------------------------
[Unit]
Description=OpenSSH per-connection server daemon
Documentation=man:sshd(8) man:sshd_config(5)
Wants=sshd-keygen.target
After=sshd-keygen.target

[Service]
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY
StandardInput=socket
--------------------------------------------------

* systemd daemon is reloaded:

 systemctl daemon-reload done, returned an empty line

Comment 7 Lukas Ruzicka 2018-03-23 15:50:50 UTC
Jakub Jelen helped me to troubleshoot my settings and he was able to find out that I misinterpreted the location of the sshd@.service file. 
After I moved the file in the correct location, the the test case works as expected.

Thank you, Jakub, very much for your help. 

I am veryfing this bug.


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