From owner-freebsd-security Wed Aug 15 7: 0:29 2001 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 136BD37B40B for ; Wed, 15 Aug 2001 07:00:21 -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.11.4/8.11.4) with SMTP id f7FDxdf80294; Wed, 15 Aug 2001 09:59:39 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 15 Aug 2001 09:59:38 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Sheldon Hearn Cc: Alexander Langer , security@FreeBSD.org Subject: Re: cvs commit: src/etc inetd.conf In-Reply-To: <59836.997879734@axl.seasidesoftware.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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