From owner-freebsd-hackers Tue Apr 23 11:51:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 03B8B37B41E; Tue, 23 Apr 2002 11:51:39 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3NIbDw00612; Tue, 23 Apr 2002 14:37:14 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 23 Apr 2002 14:37:12 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: "Greg 'groggy' Lehey" , Jordan Hubbard , Oscar Bonilla , Anthony Schneider , Mike Meyer , hackers@FreeBSD.ORG Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) In-Reply-To: <3CC5A2D9.D9FB84A3@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 23 Apr 2002, Terry Lambert wrote: > Robert Watson wrote: > > A more conservative default configuration results in a material > > improvement in system security. > > I really don't think there's any way to fully protect a > security-unconscious user, as if they had spent the time to learn what > was necessary, and chosen the right settings for their site. Nothing > can replace a system administrator who knows which end is up. I'll agree with the assertion that users unaware of a security threat, or unwilling to address a threat, are hard to prevent from shooting themselves in the feet. > I think that trying to do this is doomed to failure, in that it will > engender a false sense of security which is, in many cases, unwarranted > and dangerous. This is particularly true for FreeBSD, where the first > thing anyone ever does with the system is install packages/ports which > may themselves have undocumented security vulnerabilities (or even > documented ones for which the documentation is ignored). "System programming is hard, let's go shopping". Here I'll disagree with you: we make a concerted effort to produce a system that is safe to use. This involves a number of things, and it doesn't just mean security fixes. I would argue that we have a moral obligation to do so. Sure, we can't fix every port or package, but we do actually make an effort to take a look through the more important/common ones for obvious problems, and we are trying to move to architectures that permit ports that have previously required privilege to run with less privilege. For example, one of the projects Thomas Moestl worked on on the -CURRENT branch was to reduce the reliance on kmem access for system monitoring tools. The result is that base system tools (such as top) can now often run without any extra privilege. But a positive side effect is that many non-base system tools can also run without privilege they previously required. Someone who's unaware or unwilling to address security issues will *still* be safer if we provide a safer system. If they are going maliciously out of their way, sure, there will be problems, but if they don't need telnet, and we disable telnet by default, we have actually produced a safer system for them. And if they do need telnet, it's easy to turn on. > This is particularly true when the system is running X11, as the system > *never* *only* runs X11, but instead has all sorts of clients installed, > as well, and generally a significant set of unaudited software, such as > KDE, which you can attack via CORBA much easier than you could ever hope > to directly attack an X11 server, whose defaults already do not permit > remote connections through intrinsic access controls in the server > ("xhost", et. al.). I think you've correctly identified an area where a lot of future security work is needed. However, that doesn't negate the need for security work in the base system, because without a secure base system, you're building everything else on sand. If you have the time and resources to spend helping to kick KDE and its related dependencies into shape, I welcome your doing that. It's something I haven't had time to work with yet, but have definite future plans to do. 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-hackers" in the body of the message