Date: Tue, 23 Jan 1996 02:35:49 -0800 From: Paul Traina <pst@shockwave.com> To: Mark Murray <mark@grondar.za> Cc: Nathan Lawson <nlawson@statler.csc.calpoly.edu>, security@FreeBSD.ORG Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601231035.CAA03803@precipice.shockwave.com> In-Reply-To: Your message of "Tue, 23 Jan 1996 12:21:39 %2B0200." <199601231021.MAA01048@grumble.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Mark Murray <mark@grondar.za> Subject: Re: Ownership of files/tcp_wrappers port Paul Traina wrote: > Likewise, with eBones, we've hacked the sources to the point that its now a > HUGE job to upgrade to patch level 10. I know this, because I started it > and gave up in disgust 2 months ago. Please send me the patches, and I'll do it. I have some leave right now. They're gone...sorry, I shit-canned eBones/kerberos here in favor of ssh. You'll have to gen a copy of the patches by hand by using a copy of the pl9 and pl10 distributions, since ted never posted patches (you might ask him if he has done so since, tytso@mit.edu). > Let me state, completely, my objections to adding the tcp wrapper code: > > (a) there are several similar competing bits of code out there > that do similar things -- wrappers is not the only way to go None of them in regular use, and none as well-trusted (ubiquitous) as tcp_wrappers. None even in ports. Oh that's not true, xinetd is in regular use, but for the sake of an arguement, I'll give you 1/2 credit. > (b) it's already trivial for a user to add this support into the > base system should they desire it Sorta. I have seen some badly fouled up inetd.conf's with either total lossage (didn't work after being maimed) or massive security holes from misunderstanding. This is really a doumentation problem. we need a wrappers/general security section in the handbook. Either you're going to edit our /etc/inetd.conf to enable this stuff by default or you're going to document it. Which is it Mark? If the earlier, then you're going to screw people who don't want it to behave the way you set it up, and if the later, how is this different than documenting it properly in the handbook and pointing them at the port? > (c) incorporating it into the base system means more work to support, > test, debug, and maintain the code Has to happen in ports anyway? Ok - not to tha same degree, and I would fiercly agree with you if the software under consideration was undergoing rapid development A-La NCFTP-2 or Lynx. The small size of this software is attractive, and its stability means it does not change often enough to be a PITA. OK, so you're going to sign up to do this for the life of FreeBSD, thank you for volenteering, now given the average lifetime of contributing developers, that means we have support for ~2 years. Humm. > (d) the wrapper changes duplicate much of the access logging and > control we have already included directly in the system They also focus the same, usually in better detail. In fact wrappers are a _great_ source of logging information, and configurable from one place, too. In our last two breakins, wrapper logs nailed the culprit, and wrapper logs are great if your legacy system does not have decent accounting. One-file control of TCP access is darn useful. Great, then use them! I have no objection to you using the wrapper port on your system, I think it's a fantastic idea if you like them. As far as better detail, I certainly beg to differ. The logging that ftpd, finger, login, and friends do is far better because they have access to the application layer information that tcpd is not privy to. tcpd can only log connection attempts. Don't get me wrong, tcpd is GREAT when you have a binary only system like that garbage the "professional" unix vendors sell (harumph), but it doesn't hold a candle to real logging. > (e) they don't cover the case of UDP programs True. > If you can address these issues, then I will withdraw my objections. 80%? ;-) 15% :-) Let's separate the issue here, perhaps we can come to some sort of compromise. I would have little if any objection to putting optional calls to libwrap into our existing code in the same fashion we do stuff with with other optional parts of the system. In other words, if you wanted to add access control checking to YP or NFSD, and you put in conditional code that is only invoked if /usr/local/lib/libwrap.a is present, I won't barf all over my feet. Reasonable compromise?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601231035.CAA03803>