From owner-freebsd-security Thu Jul 13 15:38:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id ED05137B5F6 for ; Thu, 13 Jul 2000 15:38:12 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id SAA74471; Thu, 13 Jul 2000 18:38:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 13 Jul 2000 18:38:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Justin Wolf Cc: security@FreeBSD.ORG Subject: Re: Displacement of Blame[tm] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 13 Jul 2000, Justin Wolf wrote: > Maybe I missed it in this really long thread somewhere, but why do we have > to say that it concerns FreeBSD at all? If it's a bug/hole in a port, it > has nothing to do with FreeBSD except for the fact that the user MAY have > installed this port, which of course comes from a third party, but was > compiled by the FreeBSD organization. Except that we specifically modify ports to fit our environment, (a) meaning that they are not in the form provided by the software provider, (b) we compile the software with our run-time environment, (c) and we distribute the software. In each case, the opportunity for vulnerabilities arises, and like it or not, (d) by providing the software we appear to be providing some official sanctioning of the software. (a) Witness vmware, which relies on custom kernel modules for our platform, and runs with elevated privileges. (b) Witness mrg, which was vulnerable to a security problem because our ncurses library was buggy, even though the application itself was fine. (c) Witness the CDROMs we distribute, and the fact that the trend has been to migrate some of the base system behavior (fortran, etc) out into ports/packages. (d) Witness that our system installation program specifically encourages installing of the ports collection, and that many of the selling points of a FreeBSD system are features such as Samba, Apache, et al. > Instead, how about just sending an email from the FreeBSD security > 'organization' stating that a port has a bug/hole in it. No one assumes > that CERT or BUGTRAQ have any security holes, but the products they alert > about do. I think this type of advisory would provide the same > information within a context that removes FreeBSD proper of having any > connotation of holes itself. This also allows the complete removal of > 'FreeBSD' in the subject all together. Let's see -- we could just release software advisories for other people's software without discussing the relationship with FreeBSD, and appear just like the attention-grabbing pseudo-legitimate security organizations out there, or we could take responsibility for software we prepare, integrate, and distribute. I posted a message about this a few months back on bugtraq -- saying, ``Oh no, it's someone else's code'' doesn't excuse the problem if we distribute it. And every time we say, ``Well, why don't we drop that port from the ports collection,'' there are strong objections. In some cases, I believe ports have even been reenabled due to a slow response from the vendor, which I personally consider irresponsible. I'm all for a stronger disclaimer in sysinstall, carrying the same warning that our advisories do, to let people know that when they install ports they take risks. 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