Date: Thu, 13 Jul 2000 18:38:06 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Justin Wolf <jjwolf@bleeding.com> Cc: security@FreeBSD.ORG Subject: Re: Displacement of Blame[tm] Message-ID: <Pine.NEB.3.96L.1000713182841.73877B-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0007131337260.38269-100000@neo.bleeding.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000713182841.73877B-100000>