NFS tcp wrapper situation

[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
>