Date: Tue, 23 Apr 2002 17:31:05 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: "Greg 'groggy' Lehey" <grog@FreeBSD.org>, Jordan Hubbard <jkh@winston.freebsd.org>, Oscar Bonilla <obonilla@galileo.edu>, Anthony Schneider <aschneid@mail.slc.edu>, Mike Meyer <mwm-dated-1019955884.8b118e@mired.org>, hackers@FreeBSD.org Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) Message-ID: <Pine.NEB.3.96L.1020423162058.64976n-100000@fledge.watson.org> In-Reply-To: <3CC5AE6E.9622AF93@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Apr 2002, Terry Lambert wrote: > Robert Watson wrote: > > "System programming is hard, let's go shopping". > > This is exactly the phrase that comes to mind every time someone yanks > the plug on a service they are afraid might one day have an exploit > found for it. This isn't about yanking services based on blind speculation; this is about managing risk. We ship a system that has a "moderate" risk trade-off: we focus efforts on reducing risk in two ways. First, we evaluate the risk of components of the system, and focus security development efforts on improving those areas. Second, we evaluate the risk of these same components, and select system defaults in a manner that selects a reasonable balance of service and risk. This is why we've made the following classes of changes: - Changes to address specific known vulnerabilities (performed in a cooperative manner between the security-officer and the broader developer community) - Changes to reduce the privilege level required for management and monitoring applications (largely present in 5.0) - Re-implementation of core authentication components that were previously poorly integrated (PAM, ...) - Investment in improved network stack safety and firewall implementation (DARPA/NAI Labs have a contract with Jonathan Lemon that includes time spent specifically on investigating risks in the IP stack, and reducing them). There's also contract work to Jonathan Lemon to implement improved network crypto hardware integration, which he has a prototype of and will hopefully post when he's back from his current hiatus. - Evaluation of the focus of past vulnerabilities, including their source in the system code, the criticallity of the vulnerability, and the exposure associated with each vulnerability. This includes some time spent looking at how quickly various sorts of vulnerabilities tend to occur following releases, etc. - Investment in new policies and architectures improving flexibility for the administrator. Security is an area of active development in the FreeBSD Project, and we seem to have a strong grasp of a number of areas of the field. > > 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. > > "Securing telnet is hard; let's turn it off and go shopping". 8-). Or maybe, Few people use telnet any more, so we'll spend some time fixing it, but we'll also disable it by default, since many of the reports of compromise come from people who weren't even using it, but left it turned on since it was the default. > > 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. > > No one has *that* much time. Auditing that code base would be on the > order of the difficulty of auditing Windows, and we have the source code > the KDE. Certainly an in depth audit of something with the size and complexity of KDE will be a challenge; however, there's a lot of work that can be done without doing it line-by-line. > I agree that the base system needs to be secure, but I think you either > trust your security model, or you don't: X11 *does* have a security > model, even if it doesn't encrypt all the traffic over all its > connections by default. If the security model is flawed, then it needs > to be fixed, not turned off. Security models and vulnerabilities aren't necessarily related issues. Sure, a good model helps in the event there is a vulnerability, but having a good model doesn't mean you'll be invulnerable to implementation flaws, flaws in the model, etc. Personally, I had nothing to do with the choice to turn off X11, but with it now changed, I'm happy with the change. Personally, I'd recommend using SSH and letting it take care of the details. > I think it's a lot worse to leave a vulnerable telnetd turned off by > default but available to be turned on, than to have one that's > non-vulnerable turned on by default. Yeah, the great thing about vulnerabilities is that if you knew they were there you would most likely have fixed them before you released the product. Conservative defaults help you with risk you believe is present, but where you can't necessarily make the material improvement that you'd like to. In the case of telnetd, we accept that the risk exists, we attempt to improve the software, but because it's less and less frequently used and represents an attack channel for a variety of attacks, we disable it by default, but provide an easy way to re-enable it. > The fear that someone is going to find a vulnerability should be > balanced by the idea that someone is going to fix it, not balanced by > the idea that that you can hide the vulnerability by not running the > vulnerable code, "mostly". The reality is that reducing exposure is an important part of any security posture. Any additional exposure increases risk, no matter how minutely. If handled carefully, the risk of vulnerability are low: the chances are small one would be found, and/or the effects of the vulnerability may be contained. However, services that provide full authentication and credential management (such as telnetd) do badly on both fronts: the complexity and age of the code is high, and the involvement of the code in security subsystems is high. The accepted practice in the security community is to disable services presenting risk until they are necessary. The practical mapping of such a policy into FreeBSD is that inetd might be on by default, but all services in it would be disabled by default. Services would then be selectively enabled as they are needed. This is what happens in 5.0-CURRENT; recently there was some discussion regarding whether an MFC was appropriate, but I'm not sure that has worked itself out yet. 5.0-RELEASE will represent a good breaking point for that kind of change. > I guess this is a basica philosophical difference: IMO, exposure equals > the probability of a fix. Turning things off belongs in the firewall > code. In my opinion, we should focus both on reducing exposure and improving the code. I personally have tried to impact both sides of the balance, and would encourage others to do so also :-). > FWIW: I wouldn't object to a firewall rule that disallowed remote TCP > connections to the X server by default, if the firewall is enabled. I > think we already have this... The firewall code serves a useful function, but one of its great detriments is a lack of application awareness. The current placement of the policy seems most reasonable to me, but might be supplemented by such a rule if desired. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020423162058.64976n-100000>