From owner-freebsd-bugs Tue Jul 27 10:25: 2 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from fed-ef1.frb.gov (fed.frb.gov [132.200.32.32]) by hub.freebsd.org (Postfix) with ESMTP id C99EF14DE1 for ; Tue, 27 Jul 1999 10:24:56 -0700 (PDT) (envelope-from seth@freebie.dp.ny.frb.org) Received: by fed-ef1.frb.gov; id NAA20811; Tue, 27 Jul 1999 13:24:39 -0400 (EDT) Received: from m1pmdf.frb.gov(192.168.3.38) by fed.frb.gov via smap (V4.2) id xma020691; Tue, 27 Jul 99 13:24:27 -0400 Date: Tue, 27 Jul 1999 13:24:24 -0400 (EDT) From: Seth Subject: Re: bin/12819: tcpd hosts.[allow|deny] location inconsistent In-reply-to: <25569.933094518@axl.noc.iafrica.com> To: Sheldon Hearn Cc: freebsd-bugs@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org re-cc'ed to freebsd-bugs to provide closure. OK, sorry for the followup; I see the issue here. I use CTM for updates, since CVS won't work past our firewall due to dest-port restrictions. According to my CVS logs, -w was added to inetd on 7/21/1999 (delta 3.0214). Since my build is from 6/11/1999, I missed it. Searching the -stable archives, I found your announcement of 7/21 confirming the -Ww in -stable. Since this commit is so recent, I think it's even more serious a security issue, as a majority of users probably aren't running builds later than 7/21. This means that they're still relying on a tcpd in /usr/local/libexec, and that the tcpdmatch bug is still there for them. I think an announcement needs to be made to the -stable lists to the effect that "if you're using tcpdmatch to verify your tcpd allow/deny rules using the default paths and you're running a build prior to 7/21, you're in trouble unless you've ensured that /usr/local/etc/hosts.[allow|deny] and /etc/hosts.[allow|deny] are the same." In reality, people relying on tcpdmatch to verify tcpd rules are basking in a false sense of security if they aren't aware that tcpdmatch searches a different directory than tcpd does for the rulesets. This is a very bad thing. Seth. On Tue, 27 Jul 1999, Sheldon Hearn wrote: > > > On Tue, 27 Jul 1999 12:49:30 -0400, Seth wrote: > > > OK, forgive me if I'm dense here. (I did read that, btw.) > > Did you read the inetd(8) manpage? Specifically, did you see the -w and > -W command-line options? Are you starting inetd with at least -w ? > > If you don't have -w and -W, you should update your sources, rebuild and > reinstall. > > Assuming that's not your problem, > > > Here's what I now have in /etc/inetd.conf: > > > > telnet stream tcp nowait root /usr/libexec/telnetd telnetd > > Assuming that this line used to be different, did you restart inetd? > > > /usr/local/etc/hosts.[allow|deny] are symlinks to /etc/hosts[allow|deny]. > > That might work for your applications still linked against libwrap from > the ports tree, I don't know. Ideally, you want to recompile any ports > that link against libwrap. > > I'm going home now, but I'm pretty sure you have enough information > above to sort the problem out. > > Ciao, > Sheldon. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message