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(a)redhat.com

[Ralf Ertzinger]

Hi.

On Tue, 20 Jan 2009 17:18:45 -0500, Warren Togami wrote

>  * 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? 
Wait a second. iptables does not support hostnames the same way
tcpwrappers does. The userspace component may, but name resolution is
done on rule creation, not on rule matching later on.

[Warren Togami]

Ralf Ertzinger wrote:
>  Hi.
>  
>  On Tue, 20 Jan 2009 17:18:45 -0500, Warren Togami wrote
>  
> > * 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?
>  
>  Wait a second. iptables does not support hostnames the same way
>  tcpwrappers does. The userspace component may, but name resolution is
>  done on rule creation, not on rule matching later on.
>   
Yes, that is why I said "similar DNS-related conditions".  In the case 
of iptables it would be cases like forward resolver different from 
reverse, or secondary IP from forward resolver, or if the IP address 
referenced changed since iptables parsing, or if the DNS server failed 
during iptables parsing.

Warren Togami
wtogami(a)redhat.com

[Ric Wheeler]

Warren Togami wrote:
>  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. 
I disagree - you can easily get into a situation here where a user has 
put "badhost.example.com" into hosts.deny and by your argument, if DNS 
lookup fails, you will always allow them in.

Clearly, not the correct response for a security policy.

As we discussed with Steve D this afternoon, I think that the correct 
behaviour would be to:

    (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable 
this denial if no rules for your service are defined.
    (2) If you don't believe in this policy, either uninstall TCP 
wrappers OR use only IP addresses in the /etc/hosts.* files.

What you are proposing would flip the security policy on its head - if 
you cannot resolve the hostname, always allow access.

To recap, to trigger this concern you have, you have to take the 
following steps:

    (1) Edit either file and install an allow or deny rule with 
hostnames (we currently ship without any rules defined, the files are 
effectively empty)
    (2) Have a DNS failure
    (3) Have configured NFS service

The fix for a user is easy - change the hostnames to IP addresses or 
uninstall TCP wrappers, right?

I really, really don't see this as anything other than correcting a long 
standing bug.

A different (and very valid) argument can be made that tcp wrappers are 
garbage and that we should not ship them. Until then, I would argue that 
we should fix them to work as expected.

What would be nice is if tcp wrappers itself had an easy to use API that 
allowed us to query for a specific service - if no rules (default or 
specific to your service) have been specified, you can disable the DNS 
reverse lookup path.

Regards,

Ric

>  * 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(a)redhat.com
>
>

[Warren Togami]

Ric Wheeler wrote:
> >
> > * 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.
>  
>  I disagree - you can easily get into a situation here where a user has 
>  put "badhost.example.com" into hosts.deny and by your argument, if DNS 
>  lookup fails, you will always allow them in. 
My point is a sysadmin shouldn't be doing that, because it is ALWAYS a 
bad idea and a misconfiguration.  They should instead set a wildcard to 
deny everything and allow only specific hosts in /etc/hosts.allow.  Then 
the DNS-is-down or DNS-reverse-failure case properly fail as expected.

My points go on further to say that we don't second guess the bad policy 
if the user does something equally foolish with iptables, or tcp 
wrappers with sshd remains "vulnerable" in the way you are trying to 
shoe-horn into nfs-utils.

In any case I think it is a bad idea to add this to nfs-utils, but we 
did agree to do so today.  While I continue to disagree, I'm satisfied 
enough to just let it happen.  We all wasted a serious amount of time 
over this non-issue.

>  
>  A different (and very valid) argument can be made that tcp wrappers are 
>  garbage and that we should not ship them. Until then, I would argue that 
>  we should fix them to work as expected.
>   
+1.  We really need to stop shipping this crap.

Warren Togami
wtogami(a)redhat.com

[Steve Grubb]

On Tuesday 20 January 2009 11:17:15 pm Warren Togami wrote:
>  > A different (and very valid) argument can be made that tcp
> wrappers are
>  > garbage and that we should not ship them. Until then, I would argue that
>  > we should fix them to work as expected.
>
>  +1.  We really need to stop shipping this crap. 
The day when no one tries IP address spoofing and source routing is the day we 
can stop shipping this "crap". Until then I thank it for every denial I see 
in my logs.

-Steve

[Chris Adams]

Once upon a time, Steve Grubb <sgrubb(a)redhat.com&gt; said:
>  The day when no one tries IP address spoofing and source routing is
> the day we 
>  can stop shipping this "crap". Until then I thank it for every denial I see 
>  in my logs. 
Those would be good reasons, if tcpd protected you against those things.

The Linux IPv4 stack has an option "accept_source_route" that is off by
default, so that protects you there (as do most decent ISPs that disable
source routing).

TCP_wrappers does nothing to protect against IP spoofing.  Secure
sequence numbers should protect TCP, and proper network design and
filtering is the only thing that can protect UDP against spoofing.

TCP_wrappers was good before we had host-based firewalls, but is really
obsolete at this point, except for trying to do access control based on
DNS (which, for the most part, is a bad idea, as seen in this thread).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Ric Wheeler]

Chris Adams wrote:
>  Once upon a time, Steve Grubb <sgrubb(a)redhat.com&gt; said:
>    
> > The day when no one tries IP address spoofing and source routing is the day we 
> > can stop shipping this "crap". Until then I thank it for every denial I see
>
> > in my logs.
> >     
>
>  Those would be good reasons, if tcpd protected you against those things.
>
>  The Linux IPv4 stack has an option "accept_source_route" that is off by
>  default, so that protects you there (as do most decent ISPs that disable
>  source routing).
>
>  TCP_wrappers does nothing to protect against IP spoofing.  Secure
>  sequence numbers should protect TCP, and proper network design and
>  filtering is the only thing that can protect UDP against spoofing.
>
>  TCP_wrappers was good before we had host-based firewalls, but is really
>  obsolete at this point, except for trying to do access control based on
>  DNS (which, for the most part, is a bad idea, as seen in this thread).
>
>     
Sounds like it is something that we might want to try to deprecate and 
eventually remove.

ric

[Chris Adams]

Once upon a time, Ric Wheeler <rwheeler(a)redhat.com&gt; said:
>  Chris Adams wrote:
>  >TCP_wrappers was good before we had host-based firewalls, but is really
>  >obsolete at this point, except for trying to do access control based on
>  >DNS (which, for the most part, is a bad idea, as seen in this thread).
>  >  
>  Sounds like it is something that we might want to try to deprecate and 
>  eventually remove. 
I hadn't really given it much thought before this thread, but that
really may be the case (IMHO of course).

TCP_wrappers functions that are not really useful now:

- connection logging; this came when executed directly (e.g. from old
  inetd), but I don't think anything uses that now (xinetd, NFS,
  OpenSSH, etc. use their own logging instead of tcp_wrappers'); now
  that I look, I see rpcbind has a "-l" option that looks like it uses
  libwrap's logging (option is not on by default)

- basic allow/deny access control on a per-host and per-service basis;
  this can also be done with iptables for most services (and iptables is
  better, since that keeps any system daemon from even seeing a
  connection => lower load, less possible vulnerability, etc.)

- IDENT lookup (I don't believe anything uses this now)

There are some things that you can still do with TCP_wrappers that you
can't easily do in other ways:

- control access to RPC services that live on essentially random ports

- do DNS-based access control (which can seem useful but is often a bad
  idea)

- easier to manage "dynamic" access control such as done with denyhosts


The annoying thing about even considering deprecating TCP_wrappers is
that for most (if not all) current use, it is a build-time decision.  If
you build e.g. OpenSSH without -lwrap, there is no way to add that
functionality back.  Somebody could teach denyhosts about iptables
instead of /etc/hosts.deny (shouldn't be too hard to manage with a
couple of new scripts).

That brings me back to RPC services though, which means NFS (which
started all of this).  Some of the NFS component services have fixed
ports now (even though they still register with portmapper), such as
nfsd (2049) and rquotad (875), but I believe that mountd, lockd, and
statd all run on portmapper-assigned random ports.  The only way to
control access to them is currently TCP_wrappers.

Ideally, there'd be an iptables module or something that could track RPC
assigments and limit access, but that isn't a simple thing.
Alternately, you could have the portmapper have a callout to a script
that could modify iptables settings.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Jonathan Underwood]

2009/1/22 Chris Adams <cmadams(a)hiwaay.net&gt;:
[snip]
>  - easier to manage "dynamic" access control such as done
> with denyhosts
>  
[snip]
>  functionality back.  Somebody could teach denyhosts about iptables
>  instead of /etc/hosts.deny (shouldn't be too hard to manage with a
>  couple of new scripts). 
Incidentally this is precisely what fail2ban can do (i.e. use iptables
rather than /etc/hosts.deny).

J.

[Jesse Keating]

On Wed, 2009-01-21 at 18:48 -0600, Chris Adams wrote:
>   
>  That brings me back to RPC services though, which means NFS (which
>  started all of this).  Some of the NFS component services have fixed
>  ports now (even though they still register with portmapper), such as
>  nfsd (2049) and rquotad (875), but I believe that mountd, lockd, and
>  statd all run on portmapper-assigned random ports.  The only way to
>  control access to them is currently TCP_wrappers. 
However each of these do allow you to set a specific port they'll run
on, so that you /can/ use iptables with them.  I've been running them
that way for years.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Chris Adams]

Once upon a time, Jesse Keating <jkeating(a)redhat.com&gt; said:
>  On Wed, 2009-01-21 at 18:48 -0600, Chris Adams wrote:
>  > That brings me back to RPC services though, which means NFS (which
>  > started all of this).  Some of the NFS component services have fixed
>  > ports now (even though they still register with portmapper), such as
>  > nfsd (2049) and rquotad (875), but I believe that mountd, lockd, and
>  > statd all run on portmapper-assigned random ports.  The only way to
>  > control access to them is currently TCP_wrappers.
>  
>  However each of these do allow you to set a specific port they'll run
>  on, so that you /can/ use iptables with them.  I've been running them
>  that way for years. 
I saw that, but I haven't tried it myself.  I guess they still register
with portmapper (i.e. portmapper allows a program to require a specific
port; I haven't done RPC programming in at least 10 years), since that
appears to be how nfsd and rquotad work.

It looks like the init scripts already support setting this (including
for the kernel lockd using sysctl).

Is there a reason to not go ahead and do that for Fedora 11?  That would
make recommending iptables instead of tcp_wrappers a lot easier.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Thomas Moschny]

2009/1/22 Jesse Keating <jkeating(a)redhat.com&gt;:
>  However each of these do allow you to set a specific port they'll
> run
>  on, so that you /can/ use iptables with them.  I've been running them
>  that way for years. 
Unless there are bugs like this one:
https://bugzilla.redhat.com/show_bug.cgi?id=458448 (YP, not NFS, but
anyway).

-- 
Thomas Moschny <thomas.moschny(a)gmail.com&gt;

[Steve Grubb]

On Tuesday 20 January 2009 08:19:25 pm Ric Wheeler wrote:
>  > * 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.
>
>  I disagree - you can easily get into a situation here where a user has
>  put "badhost.example.com" into hosts.deny and by your argument, if DNS
>  lookup fails, you will always allow them in.
>
>  Clearly, not the correct response for a security policy. 
Generally, you should put allow rules and not the reverse. If you want a 
bulletproof security policy, you have to have ALL: ALL in hosts.deny so that 
any failure results in denial. What the deny file can safely be used for is 
excluding a network you control from a larger selection. IOW, you allow all 
of the 192.168. network except for the 192.168.1. subnet. But even then you 
can use the EXCEPT operator in the allow file for this condition. So, you 
likely do not need to ever put something in the deny file other than ALL: 
ALL.


>  As we discussed with Steve D this afternoon, I think that the
> correct
>  behaviour would be to:
>
>      (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable
>  this denial if no rules for your service are defined.
>      (2) If you don't believe in this policy, either uninstall TCP
>  wrappers OR use only IP addresses in the /etc/hosts.* files. 
Look at hosts_access(5) for the rules governing tcp_wrappers. They haven't 
changed in a long long time.


>  What you are proposing would flip the security policy on its head -
> if
>  you cannot resolve the hostname, always allow access.
>
>  To recap, to trigger this concern you have, you have to take the
>  following steps:
>
>      (1) Edit either file and install an allow or deny rule with
>  hostnames (we currently ship without any rules defined, the files are
>  effectively empty)
>      (2) Have a DNS failure
>      (3) Have configured NFS service
>
>  The fix for a user is easy - change the hostnames to IP addresses or
>  uninstall TCP wrappers, right? 
Or rewrite the rules from the mostly closed perspective which means you deny 
everyone and allow some connections.


>  I really, really don't see this as anything other than correcting
> a long
>  standing bug.
>
>  A different (and very valid) argument can be made that tcp wrappers are
>  garbage and that we should not ship them. Until then, I would argue that
>  we should fix them to work as expected. 
They are working just as expected. 


>  What would be nice is if tcp wrappers itself had an easy to use API
> that
>  allowed us to query for a specific service - if no rules (default or
>  specific to your service) have been specified, you can disable the DNS
>  reverse lookup path. 
What some services do is have a configuration flag that tells the daemon 
whether or not to use tcp_wrappers. This way you have an escape hatch if 
you'd rather write iptables rules.

-Steve

[Ric Wheeler]

Steve Grubb wrote:
>  On Tuesday 20 January 2009 08:19:25 pm Ric Wheeler wrote:
>    
> >> * 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.
> >>       
> > I disagree - you can easily get into a situation here where a user has
> > put "badhost.example.com" into hosts.deny and by your argument, if DNS
> > lookup fails, you will always allow them in.
> >
> > Clearly, not the correct response for a security policy.
> >     
>
>  Generally, you should put allow rules and not the reverse. If you want a 
>  bulletproof security policy, you have to have ALL: ALL in hosts.deny so that 
>  any failure results in denial. What the deny file can safely be used for is 
>  excluding a network you control from a larger selection. IOW, you allow all 
>  of the 192.168. network except for the 192.168.1. subnet. But even then you 
>  can use the EXCEPT operator in the allow file for this condition. So, you 
>  likely do not need to ever put something in the deny file other than ALL: 
>  ALL.
>
>     
I don't disagree with the best way to use it as you suggest, but the 
specific issue is for those who (naively?) put a hostname into the deny 
file. I don't think that we can assume that users will always do the 
optimal thing :-)

The way the code works today, you will get the expected behavior (mounts 
from that client are denied) only as long as DNS is working properly. 
When the DNS lookup fails, it will be allowed.

ric

>    
> > As we discussed with Steve D this afternoon, I think that the correct
> > behaviour would be to:
> >
> >     (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable
> > this denial if no rules for your service are defined.
> >     (2) If you don't believe in this policy, either uninstall TCP
> > wrappers OR use only IP addresses in the /etc/hosts.* files.
> >     
>
>  Look at hosts_access(5) for the rules governing tcp_wrappers. They haven't 
>  changed in a long long time.
>
>
>    
> > What you are proposing would flip the security policy on its head - if
> > you cannot resolve the hostname, always allow access.
> >
> > To recap, to trigger this concern you have, you have to take the
> > following steps:
> >
> >     (1) Edit either file and install an allow or deny rule with
> > hostnames (we currently ship without any rules defined, the files are
> > effectively empty)
> >     (2) Have a DNS failure
> >     (3) Have configured NFS service
> >
> > The fix for a user is easy - change the hostnames to IP addresses or
> > uninstall TCP wrappers, right?
> >     
>
>  Or rewrite the rules from the mostly closed perspective which means you deny 
>  everyone and allow some connections.
>
>
>    
> > I really, really don't see this as anything other than correcting a long
> > standing bug.
> >
> > A different (and very valid) argument can be made that tcp wrappers are
> > garbage and that we should not ship them. Until then, I would argue that
> > we should fix them to work as expected.
> >     
>
>  They are working just as expected. 
>
>
>    
> > What would be nice is if tcp wrappers itself had an easy to use API that
> > allowed us to query for a specific service - if no rules (default or
> > specific to your service) have been specified, you can disable the DNS
> > reverse lookup path.
> >     
>
>  What some services do is have a configuration flag that tells the daemon 
>  whether or not to use tcp_wrappers. This way you have an escape hatch if 
>  you'd rather write iptables rules.
>
>  -Steve
>

[Warren Togami]

Ric Wheeler wrote:
>  
>  I don't disagree with the best way to use it as you suggest, but the 
>  specific issue is for those who (naively?) put a hostname into the deny 
>  file. I don't think that we can assume that users will always do the 
>  optimal thing :-) 
Exactly the same thing can be said about misconfiguration with iptables.

Why is misconfigured tcp wrappers important enough to second guess, 
while misconfigured iptables is not?

This is one of the key reasons why this is NOT A BUG, and it does not 
belong in nfs-utils upstream.

If the concern is for the behavior to match the man page, the man page 
should have big fat warnings, it NEVER a good idea to use hostnames in 
/etc/hosts.deny.

Warren Togami
wtogami(a)redhat.com