Date: Wed, 15 Aug 2001 09:59:38 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Alexander Langer <alex@big.endian.de>, security@FreeBSD.org Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <Pine.NEB.3.96L.1010815094918.80130B-100000@fledge.watson.org> In-Reply-To: <59836.997879734@axl.seasidesoftware.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 Aug 2001, Sheldon Hearn wrote: > On Wed, 15 Aug 2001 13:48:52 +0200, Alexander Langer wrote: > > > We can disable binding to port 25 and local mail delivery will still > > work. I also like disabling all other network services by default. > > One of OpenBSD's argument is, that you then know what services you've > > had enabled, and you then know, what to take care about. If you > > missed a SA about some service you haven't enabled either, who cares? > > The only problem here is that FreeBSD could be seen as a system that > does nothing out of the box. :-) > > This is not an unresolvable problem, it's just something that needs to > be considered. Well, we're already not a web server out of the box, or a decent workstation out of the box, or able to serve files to Windows systems. Many common uses of FreeBSD require using packages, and I think that's a fine approach. We have a strong binary packaging solution that makes it easy for our users to install a variety of well-supported software packages providing these additional services. That said, the way we have addressed this recently is to disable services by default, but make it easier to turn them on. For example, to provide an interactive prompt to enable the service during install, and provide a sysinstall menu option to twiddle it post-install. This is true of both base system services (NFS, etc), and package ones (we provide special hooks to allow things like Linux emulation to be properly enabled, and so on). Part of the problem we seem to be bumping into is that the scope of "reasonable defaults" can be conservative only if administering the machine is straight forward. Otherwise you have to turn things on because no one wants to invest the time to figure out how. In that case, the problem isn't with changing the defaults, it's with the administrative tools. A quick glance at past security advisories demonstrates that *every* significant (and many insignificant) remotely accessible base system service on FreeBSD has suffered a vulnerability in the base install in the past. This includes ftpd, telnetd, sshd, sendmail, and even fingerd. And of these, at least two or three have been in the past six months. We review our source code carefully, and others who review their code carefully have the same problem (including the OpenBSD project). The only reasonable remedy to a scenario that assumes inevitable failure is to reduce the opportunity and hence reduce the risk. This means choosing conservative defaults, but making it easier for users to manage the set of services they provide via the system. That's why I've spent some time both disabling services by default, and attempting to make up for that with sysinstall changes. I'm pretty good at turning off services, but I make no claims about experience with user interface design. I'd welcome others to work towards the same goals. None of this precludes continuing to improve the quality and correctness (and hence security) of our code base, it just means we need to accept that a complete solution requires a more comprehensive look at the problem, addressing a variety of issues relating to architecture, implementation, and usability. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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.1010815094918.80130B-100000>