Date: Wed, 24 Apr 2002 09:06:55 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Robert Watson <rwatson@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: <20020424090655.O6425@wantadilla.lemis.com> In-Reply-To: <Pine.NEB.3.96L.1020423110123.64976j-100000@fledge.watson.org> References: <20020423131646.I6425@wantadilla.lemis.com> <Pine.NEB.3.96L.1020423110123.64976j-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 23 April 2002 at 11:13:42 -0400, Robert Watson wrote: > > 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. *snip* > A reasonable set of criteria might include: > > - There have been past vulnerabilities that were exploitable by having the > feature enabled by default. Which in this case? > - The complexity and exposure of the feature lends it to future > vulnerabilities. I don't see any relevance here. > - Turning the feature on is difficult or impossible without high levels of > expertise. Fortunately, this is the case here as well. Otherwise it would really have broken X. > - The feature does/does not have more secure alternatives accepted by the > broader community. The broader community hasn't been consulted here. > "Security by obscurity" does not refer to the act of selecting a > conservative security policy, Don't get hung up on terminology. >> 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. > > 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?". What I'm talking about here are differences which users of other UNIX systems won't know about and which will make life difficult for them, to the extent that the casual user won't bother to try to solve the problem. In the current issue of AUUGN, the journal of the Australian UNIX User group (http://www.auug.org.au/), we gave away a FreeBSD 4.5 CD-ROM. Based on previous actions, I'm expecting a number of people to try it out. They're mainly experienced UNIX users; they won't want to go reading through 80 pages of man pages when their X fails to work. They'll throw away the CD and go back to what they were using before. >> 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 That's not the correct word. > 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. I think the issue here is that individuals make this kind of decision. We need a broader consensus for this kind of change. As Jochem points out, only 3 people were involved in the decision, all of them people with security profiles which weren't affected by this change. > 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. There's another issue here. This isn't the first port I've seen which has made gratuitous changes to the original package. By "gratuitous" I mean changes which are not necessary for making the package work under FreeBSD. If people want to modify the behaviour of the package, they should create a second port which clearly identifies that the behaviour has been changed from the default. > 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. Have you tried doing that with a Sun 3/60? Or with an AIX box? This fix even stops connections from the same machine if you use a domain name display format (echunga:0.2 instead of :0.2). > BTW, my notion of ease of use for services would be something like the > following: ... My notion of ease of use would be dependent on the securelevel. I run a network which is heavily firewalled (has to be: I have Linux boxes here too :-), and within which the security is very lax. I have yet to see any proof that this is a problem. Sure, set the machine up for secure operation by default, and issue dire warnings about relaxing security, but don't try to know better than the user. Greg -- See complete headers for address and phone numbers 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?20020424090655.O6425>