Date: Wed, 1 Dec 1999 14:12:53 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Bill Swingle <unfurl@dub.net> Cc: security@freebsd.org, Jordan Hubbard <jkh@freebsd.org> Subject: Re: [btellier@USA.NET: Several FreeBSD-3.3 vulnerabilities] Message-ID: <Pine.BSF.3.96.991201141151.4689D-100000@fledge.watson.org> In-Reply-To: <19991201093242.A71817@dub.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I think you make a number of excellent points--that these are third party applications, that we're getting toasted on bugtraq, and that we probably did slip up somewhere and we should figure it out. I'd like to address them individually. 1) These are third party applications, and as Jordan points out, there is no feasible way for the FreeBSD project and its supporters to individually review all of the code, especially given that it isn't even in our CVS tree! That said, I think we should make it *more clear* that packages are not our responsibility to secure -- for example, I'd like to see a specific dialog pop up before entering the packages collection in sysinstall indicating that the code is a third-party add-on package that may not have gone through the same rigorous code review process used for the base FreeBSD source distribution, and as such may suffer from security limitations. Similarly, it might be nice to have a * beside package entries for packages that need elevated privileges (setuid, run from inetd, etc) to indicate that this is security sensitive code. We know that really all code is security sensitive (especially if root ever runs it) but this would be a start. Another issue here, though, is that we do choose the permissions that files get installed in, as well as the paths. Do these programs try to install themselves setuid/setgid/etc by default, or is that an ease-of-use thing we add? Wouldn't it be better to require users to be in the dialer group to dial, than having seyon run with dialer setgid? (or whatever the example was) 2) We're getting toasted on bugtraq, and it's not clear that it's our fault. We should determine if we have some responsibility for this, and also if the bugs are present on other platforms. If it's not our fault, we should post a rebuttal pointing out why it is not or partially our fault. I'm all for taking responsibility, but not for other people's problems :-). A serious post on bugtraq indicating the limitations on reviewing third party code, and a discussion of the implications of package systems (such as .deb, .rpm, .tgz..) with regards to auditing and distribibution responsibility would probably be a good idea, and raise the issue for application developers as well. 3) The loss of the bug reports as described is concerning -- but not surprising. Contacting the maintainers of ports can be extremely difficult, and even more so for them to contact the authors of the ports. In many cases, application developers aren't interested in the fact that we ported to FreeBSD (and in some cases, don't even know :-). If they don't even know it's been ported, they're probably not responsible for verifying that it runs securely, although they are responsible for stupid things like buffer overflows. We should probably include commentary on reporting application/port bugs in a post describing our opinions on third party packages. I'm not sure what the best information/workflow solution is. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991201141151.4689D-100000>