From Fedora Project Wiki
(clarify the deprecation is about removal of -devel subpackage only)
Line 40: Line 40:
  
 
== Scope ==
 
== Scope ==
* Proposal owners: Deprecate tcp_wrappers in Fedora, remove dependency on other packages maintained and notify other maintainers to follow the same procedure. Potentially only remove <code>tcp_wrappers-devel</code> subpackage to avoid new packages building against it.
+
* Proposal owners:
 +
** Deprecate tcp_wrappers in Fedora:
 +
*** Remove dependency on other packages maintained and notify other maintainers to follow the same procedure.
 +
*** Remove <code>tcp_wrappers-devel</code> subpackage to avoid new packages building against it before Mass Rebuild (31st January 2018).
 
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
  
Line 52: Line 55:
 
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
 
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
  
* Policies and guidelines: If package will not be retired, update packaging guidelines to NOT RECOMMEND building against tcp_wrappers <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* Policies and guidelines: Update packaging guidelines to NOT RECOMMEND building against tcp_wrappers after the removal. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
 
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
  
Line 66: Line 69:
 
You should be able to run system (for example with OpenSSH) without tcp_wrappers package.
 
You should be able to run system (for example with OpenSSH) without tcp_wrappers package.
  
For example, OpenSSH daemon should not be linked with libwrap. The following command should not return anything:
+
For example, OpenSSH nor OpenLDAP daemons should not be linked with libwrap. The following command should not return anything:
  
 
  ldd /usr/sbin/sshd  | grep libwrap
 
  ldd /usr/sbin/sshd  | grep libwrap
 +
ldd /usr/sbin/slapd  | grep libwrap
 +
 +
There should be no tcp_wrappers-devel package in the system:
 +
 +
rpm -q tcp_wrappers-devel
  
 
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
 
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
Line 85: Line 93:
  
 
== User Experience ==
 
== User Experience ==
Users should not notice any difference. System administrators will have to configure different layer of security, if tcp_wrapper was the only one they relied on.
+
Users should not notice any difference. System administrators should configure different layer of security, if tcp_wrapper was the only one they relied on.
  
 
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
 
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
Line 157: Line 165:
 
* Contingency mechanism: tcp_wrappers package will not be retired, offending packages will still carry this dependency, but guidelines should be updated to not recommend building against this package <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Contingency mechanism: tcp_wrappers package will not be retired, offending packages will still carry this dependency, but guidelines should be updated to not recommend building against this package <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
 
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: Beta freeze? <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* Contingency deadline: Beta freeze (2018-03-06) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 165: Line 173:
 
=== Migration to tcpd ===
 
=== Migration to tcpd ===
  
After removing the libwrap dependency from the openssh, it will stop using rules defines in <code>/etc/hosts.deny</code>. The functionality can be added back to any socket-activated service, if the tcp_wrappers package will not be removed from fedora. For example SSHD:
+
After removing the libwrap dependency from the openssh, it will stop using rules defines in <code>/etc/hosts.deny</code>. The functionality can be "added back" if needed to any socket-activated service. For example SSHD:
  
 
* Disable <code>sshd.service</code>
 
* Disable <code>sshd.service</code>
Line 175: Line 183:
 
  cp {/usr/lib,/etc}/systemd/system/sshd@.service
 
  cp {/usr/lib,/etc}/systemd/system/sshd@.service
  
* Modify the <code>ExecStart</code> line in the above file under <code>/ect/</code> from
+
* Modify the <code>ExecStart</code> line in the above file under <code>/etc/</code> from
  
 
  ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY</code>
 
  ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY</code>
Line 212: Line 220:
  
 
== Release Notes ==
 
== Release Notes ==
Fedora 28 removes support for tcp_wrappers (aka <code>/etc/hosts.deny</code> access files). The preferred replacement is software firewalld/nftables rules or software specific access rules for more complex filtering. If your system security depends on tcp_wrappers rules, convert them to firewall, or set up <code>tcpd</code> to do the same job for you.
+
Fedora 28 removes support for tcp_wrappers (aka <code>/etc/hosts.deny</code> access files) by default. The preferred replacement is software firewalld/nftables rules or software specific access rules for more complex filtering. If your system security depends on tcp_wrappers rules, convert them to firewall, or set up <code>tcpd</code> to do the same job for you.
  
 
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
 
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->

Revision as of 14:45, 4 January 2018

Deprecate TCP wrappers

Summary

TCP wrappers is a simple tool to block incoming connection on application level. This was very useful 20 years ago, when there were no firewalls in Linux. This is not the case for today and connection filtering should be done in network level or completely in application scope if it makes sense. After recent discussions I believe it is time to go for this package, if not completely, than at least as a dependency of modern daemons in system by default.


Owner

  • Name: Jakub Jelen
  • Email: jjelen@redhat.com
  • Release notes owner:

Current status

Detailed Description

Last version of tcp_wrappers was released 20 years ago (with later addition of IPv6 support). At that time, it was very powerful tool to "block all traffic", but these days we can do the same thing using firewalls/iptables/nftables for all traffic on network level or similar filtering exists in most of the applications.

One of the motivating factors for this change was removal of TCP wrappers support from systemd and openssh in 2014, based on the thread on fedora devel list [1]. I started another thread during 2017 [2] which is trying to explain the reasons why we should do that with other constructive ideas.

Another factor which has driven the deprecation of this package is the lack of any upstream community around it. Although the threats on networking communications increase, the threat coverage of this package has remained the same the last two decades, suggesting that new threats are now being handled on different components.


Benefit to Fedora

Removing this package from Fedora will remove a package from default and minimal installations (removing dependency of daemons such as SSHD). It also makes the configuration straight-forward for new users (no shared files defining access rules, poorly reporting any errors to users.

Removing the dependency from all packages and retiring the package in single release will minimize users confusion and avoids opening sensitive services after the update.


Scope

  • Proposal owners:
    • Deprecate tcp_wrappers in Fedora:
      • Remove dependency on other packages maintained and notify other maintainers to follow the same procedure.
      • Remove tcp_wrappers-devel subpackage to avoid new packages building against it before Mass Rebuild (31st January 2018).
  • Other developers: Remove dependency of your software on tcp_wrappers. See Dependencies section for more information.
  • Policies and guidelines: Update packaging guidelines to NOT RECOMMEND building against tcp_wrappers after the removal.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

Updating from older versions might expose existing services "protected" by tcp_wrappers before (sshd). The removal needs to be explicitly mentioned in the migration guide/release notes so the users are able to configure different layer of security (firewalld, application configuration) if this was the only one they used.


How To Test

You should be able to run system (for example with OpenSSH) without tcp_wrappers package.

For example, OpenSSH nor OpenLDAP daemons should not be linked with libwrap. The following command should not return anything:

ldd /usr/sbin/sshd  | grep libwrap
ldd /usr/sbin/slapd  | grep libwrap

There should be no tcp_wrappers-devel package in the system:

rpm -q tcp_wrappers-devel


User Experience

Users should not notice any difference. System administrators should configure different layer of security, if tcp_wrapper was the only one they relied on.


Dependencies

Other packages should be rebuilt without support for tcp_wrappers (if possible). That should be at most tens lines of code change, configure option (if upstream still supports it) or dropping downstream patch.

The list of packaged still using tcp_wrappers, based on the dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64 and manual removal of duplicates and packages building against net-snmp (therefore indirectly depending on libwrap):

  • 389-ds-base
  • aeskulap
  • apcupsd
  • apt-cacher-ng
  • audit
  • bacula
  • bacula2
  • conserver
  • ctk
  • cyrus-imapd
  • dcmtk
  • dovecot
  • exim
  • flow-tools
  • gsi-openssh
  • net-snmp
  • nfs-utils
  • ngircd
  • nrpe
  • openldap
  • openssh
  • pptpd
  • prelude-manager
  • proftpd
  • pulseaudio
  • quota
  • redir
  • rpcbind
  • rwhoisd
  • sendmail
  • slapi-nis
  • socat
  • sslh
  • stunnel
  • syslog-ng
  • tftp
  • up-imapproxy
  • uwsgi
  • vsftpd
  • xinetd
  • yaz

If you wish to maintain compatibility with old releases/you can adjust spec file in the similar way how ocserv does it:

%if 0%{?fedora} >= 28 || 0%{?rhel} > 7
%define use_libwrap 0
%else
%define use_libwrap 1
%endif
...
%if %{use_libwrap}
	--with-libwrap
%else
	--without-libwrap
%endif


Contingency Plan

  • Contingency mechanism: tcp_wrappers package will not be retired, offending packages will still carry this dependency, but guidelines should be updated to not recommend building against this package
  • Contingency deadline: Beta freeze (2018-03-06)
  • Blocks release? No

Documentation

Migration to tcpd

After removing the libwrap dependency from the openssh, it will stop using rules defines in /etc/hosts.deny. The functionality can be "added back" if needed to any socket-activated service. For example SSHD:

  • Disable sshd.service
systemctl disable sshd
  • Copy the shipped sshd@.service to /etc:
cp {/usr/lib,/etc}/systemd/system/sshd@.service
  • Modify the ExecStart line in the above file under /etc/ from
ExecStart=-/usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY

to

ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS $CRYPTO_POLICY
  • Reload systemctl
systemctl daemon-reload
  • Enable and start sshd.socket
systemctl enable sshd.socket
systemctl start sshd.socket
  • Verify that you can connect to new service (not working now, because it is blocked by SELinux). Blocked by the bug #1482554 [3].

Similar approach can be used for other services, that will drop tcp_wrappers dependency.

Migration to systemd eBPF-based filter

SystemD 235 implemented eBPF-based filter for services. This provides a new options IPAddressAllow and IPAddressDeny for units. It is not restricted to socket-activated services, but because it is enforced on the kernel level, it can seamlessly work with standard services.

One can simply allow access to sshd service only from IP address 192.168.0.42 by creating a drop-in unit file in

IPAddressAllow=192.168.0.42

To implement similar effects as tcp_wrappers do for multiple services, you can apply these rules for whole system in system.slice.

Migrate to application-specific filters

Most of the tools currently support its own way of filtering traffic. For example, OpenSSH Match blocks can be used to disable authentication from specific IP addresses or hostnames (with UseDNS yes) or mod_wrap2 for ProFTPD, which allows even more flexibility.


Release Notes

Fedora 28 removes support for tcp_wrappers (aka /etc/hosts.deny access files) by default. The preferred replacement is software firewalld/nftables rules or software specific access rules for more complex filtering. If your system security depends on tcp_wrappers rules, convert them to firewall, or set up tcpd to do the same job for you.