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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
