NFS tcp wrapper situation

[Warren Togami]

https://bugzilla.redhat.com/show_bug.cgi?id=480420#c17

Here is some background information of how this happened.  A long
standing bug in NFS since August 2000 is that it did not support tcp
wrappers /etc/hosts.deny and /etc/hosts.allow.  This was fixed upstream,
but then they discovered an issue.

/etc/hosts.deny:
mountd: badhost.example.com

If DNS is down or the source IP address lacks a reverse lookup, then it
has no way of knowing that it is meant to be denied.  It allows the
connection.  This was considered to a be an unacceptable bug.  If
someone specifies a hostname, from a security perspective they expect
the failure case to err to the side of caution and deny by default if
cannot affirm that the incoming client is not a listed denied hostname.
  Thus "deny upon reverse DNS failure" became the default behavior in
nfs-utils.

This manifested in F-9 and F-10 with a many people suddenly unable
to NFS mount after nfs-utils update hit mirrors ~January 14th.  This is
especially problematic in cases where people use caching DNS
nameservers, as it is non-trivial to explain to everyone how to setup a
proper DNS for arbitrary addresses.  These individuals might also have
no control over DNS on their network.

I believe that "hostname in /etc/hosts.deny fails to deny" should be
NOTABUG for several reasons:

* BAD POLICY and MISCONFIGURATION.
TCP wrappers is behaving exactly how it is defined in policy.  Hostname
in hosts.deny (itself always a bad idea) is dependent on the DNS server
to be properly configured and operating.  Failure due to hostnames in
/etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
unknown clients connecting to that service, then they should use a
wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
/etc/hosts.allow.
* Host names in iptables or tcp wrappers rules are ALWAYS a bad idea
because you are relying upon an unreliable and insecure external data
source that is DNS.  DNS can be too easily spoofed, hijacked, denial of
service attacked, and it lacks any semblance of authentication or
encryption.
* It is wrong for a service wrapped by tcp wrappers to over-engineer
itself to workaround misconfiguration on the part of the sysadmin.
* It is inconsistent with the behavior of any other service wrapped by
tcp wrappers.  "sshd: badhost.example.com" allows incoming connections
if reverse DNS lookup fails.  Does this mean sshd and every other
service wrapped by tcp wrappers should also be modified?
* This is inconsistent with iptables.  "iptables -A INPUT -p tcp --dport
22 -s badhost.example.com -j REJECT" might also fail to reject an
incoming connection under similar DNS-related conditions.  It would be
clearly wrong for sshd to second-guess and parse iptables rules, and
make its own decision based its own reverse DNS query matching hostnames
found in those iptables rules.  Why is it OK to second guess tcp
wrappers but not iptables?
* Even if we agree that this is a bug that should be fixed and not
simply sysadmin misconfiguration, the correct layer to fix it is in tcp
wrappers itself, not the individual wrapped services.

We had a lengthy discussion and have come to reluctant agreement on how
to proceed from here.  It was decided by the filesystem people that even
if it is only the result of misconfiguration, nfs-utils should protect
and deny by default.

Steve is working on the next build of nfs-utils with slightly different
logic.  It will behave exactly as it did before this change (no tcp
wrappers or deny on reverse DNS lookup failure).  It will only enable
tcp wrapper and the new denial behavior if any mountd, statd or wildcard
lines appear in /etc/hosts.deny or /etc/hosts.allow.

We will hopefully have a new build tomorrow.

Workarounds until this is fixed...
==================================
1) Remove tcpwrappers (if you don't need quotas this might be OK)
2) Downgrade nfs-utils to these versions:
http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.2/7.fc9/
http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.4/4.fc10/
3) For LTSP users, you can opt to stop using NFS entirely.  LTSP users
can switch to NBD instead, which is a little more work, but clients boot
a little faster.
https://fedorahosted.org/k12linux/NBDRootConfiguration

Warren Togami
wtogami at redhat.com