Date: Tue, 23 Apr 2002 11:13:42 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> Cc: 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.1020423110123.64976j-100000@fledge.watson.org> In-Reply-To: <20020423131646.I6425@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Apr 2002, Greg 'groggy' Lehey wrote: > On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote: > >> That fix relies on the extensive PAM updates in -CURRENT however; in > >> -STABLE it can probably be similarly replicated via appropriate tweaking > >> of sshd (?). > > > > Why not fix it in stable by the very simple tweaking of the > > ChallengeResponseAuthentication to no in the sshd config file we ship > > Trust me, this question is going to come up a _lot_ for us otherwise. :( > > I've been noticing a continuing trend for more and more "safe" > configurations the default. I spent half a day recently trying to find > why I could no longer open windows on my X display, only to discover > that somebody had turned off tcp connections by default. A more conservative default configuration results in a material improvement in system security. This is especially the case for older system features that aren't being used by many current users. For example, the choice to move to telnetd turned off by default is particularly justified these days because we have a better option: SSH. There have even been serious discussions about not installing telnetd by default, although personally I see no problem installing it. The risks with telnetd on by default have been felt: witness the telnetd vulnerability that turned up last year. Highly complex server code enabled by default isn't useful, it's a security risk. Given these basic facts, you can then argue about what features fall into this category, and we can go on regarding that for a while. A reasonable set of criteria might include: - There have been past vulnerabilities that were exploitable by having the feature enabled by default. - The complexity and exposure of the feature lends it to future vulnerabilities. - Turning the feature on is difficult or impossible without high levels of expertise. - The feature does/does not have more secure alternatives accepted by the broader community. ... "Security by obscurity" does not refer to the act of selecting a conservative security policy, because "Security by obscurity" already refers to something else: relying on the level of knowledge of the attacker regarding your configuration. Since we can demonstrate disabling telnetd by default improves security, it is by definition not security by obscurity. And frankly, that applies to X11 also. "Security by obscurity" might be argued to include the S/Key behavior in the older sshd, where S/key prompts are displayed for a user even though they could not be used to log in. Frankly, I think such an argument would be reasonable. In fact, so reasonable that in -CURRENT, we don't have this behavior by default: we don't offer the S/Key authentication method to a user unless they can authenticate using S/Key. The old behavior can be turned back on via a pam.d flag for the skey module. BTW, there's a lot to be said for not throwing out the baby with the bathwater: disabling challenge response or S/Key by default isn't the right answer either. The right fix is to remove the counter-intuitive behavior regarding S/Key. > I have a problem with this, and as you imply, so will a lot of other > people. As a result of this sort of thing, people trying to migrate > from other systems will probably just give up. I certainly would have. > While it's a laudable aim to have a secure system, you have to be able > to use it too. I'd suggest that we do the following: > > 1. Give the user the choice of these additional features at > installation time. Recommend the procedures, but explain that you > need to understand the differences. We've spent some time working on this, and will continue to do so. But we also need to avoid over-burdening the install with "Do you want to turn on (this obsolete feature that some FreeBSD hacker loves and no one uses), even though it increases security risk?". Rather, we need a decent management interface. > 2. Document these things very well. Both this ssh change and the X > without TCP change are confusing. If three core team members were > surprised, it's going to surprise the end user a whole lot more. > We should at least have had a HEADS UP, and we probably need a > security policy document with the distributions. Part of your confusion is probably because X11 isn't part of the base system, so events concerning the X11 port don't tend to get discussed much on the general-purpose mailing lists. These kinds of things do get discussed on the release engineering lists, questions, etc. It may be we need a "ports release notes", but that's an effort that's going to have to come out of the ports space. BTW, another reason few people noticed is that at this point, the accepted best practice for X11 forwarding is to use SSH, which can forward TCP-based X11 to the unix domain socket X11 communication primitive. The result is that X11/TCP turned off on your workstation doesn't limit access when you log into remote servers using SSH, as long as you have X11 forwarding enabled for the server you're logging into. BTW, my notion of ease of use for services would be something like the following: a menu with a tree of services organized by category, with easy click options to turn them on and off. I played with looking at something like that for inetd.conf, but the best option was to toss the user into the editor with a bit of warning. So that's what I stuck in sysinstall. Fundamentally, we don't offer a decent management paradigm for the majority of the base system or the applications. That's the problem that needs addressing, and I would argue your effort would be better placed fixing that problem. The choices regarding disabling features and services by default have generally been made carefully, with lots of discussion, and based on a fairly rational process balancing functionality and security. 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.1020423110123.64976j-100000>