Date: Tue, 23 Apr 2002 21:38:38 -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.1020423205451.55944H-100000@fledge.watson.org> In-Reply-To: <20020424090655.O6425@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: > > A more conservative default configuration results in a material > > improvement in system security. > > *snip* By snipping here, you removed reference to the fact that this was a general discussion of direction and policy, rather than specifically to do with X11, which provides an answer to a number of your questions. > > 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? As indicated, not all of these criteria may apply in every case -- this was just a suggested list of criteria that might be applied. There have been a number of vulnerabilities in a number of different X protocol implementations. Many of them require first getting past the normal X access control mechanisms before they may be exploited, but not all. > > - The complexity and exposure of the feature lends it to future > > vulnerabilities. > > I don't see any relevance here. If you think that's a problem, then you didn't read my e-mail. However, there is actually a great deal of relevance here: protocol and implementation complexity have a lot to do with the chances that there will be a serious vulnerability. Likewise, the level of privilege associated with X11 is highly relevant: if you compromise the X server, you've got a lot to play with. > > - 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. Sounds good to me. > > - The feature does/does not have more secure alternatives accepted by the > > broader community. > > The broader community hasn't been consulted here. Not entirely clear, but worth discussing. > > "Security by obscurity" does not refer to the act of selecting a > > conservative security policy, > > Don't get hung up on terminology. If you can't use terminology properly, we'll have a lot of trouble holding a useful conversation. I objected to your use of the term, because it has a specific meaning, and that meaning doesn't apply here. If you're not going to use the term, maybe we agree on more than we think. > 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. I'm more interested in the general issue here, since you made the general assertion that there was a problem that stretched beyond this one issue. I'm happy to entertain the idea that we discuss this specific issue in more detail. In particular, the decision to not bind the X11 port might take into account this particular implementation (XFree86), and whether we can make this setting more accessible to the administrator (i.e., something that could be mechanically twiddled, rather than through manual editing of scripts...) > >> 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. Not your confusion, rather, the general confusion regarding where the feature change can/should be documented, and how people should be made aware of this kind of change. > > 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. For something like X11, we need a freebsd-x11 mailing list. Or maybe freebsd-xfree86. For most other large third party applications, we either have a single authoritative maintainer, or a mailing list. For example, both Gnome and KDE have these. > > 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. We adapt a number of applications for the FreeBSD environment and configuration. A more common way to distinguish our localizations is through a WITH_GRATUITOUS_LOCAL_CHANGES make argument, or via an interactice interface (for example, ghostscript). > > 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). Obsolete hardware is not an excuse for avoiding continued development. The AIX argument is more valid :-). Unfortunately, I got rid of my Sun 3/60 a few years ago. Good for a space heater, though... > > 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. Securelevels are a specific security model that doesn't relate to this at all. Arguably, securelevels contribute more to shoot footing than about any other feature we provide easy access to with sysinstall. I'd rather leave securelevels as they are: a model restricting root privilege, and not tangle them into any more features than necessary. Securelevels are *not* a good model for security management, although they might act as a tool in a general security posture. The "security profile" concept has provided for similar confusion and problems -- witness NFS breaking between our platform and others because someone selected the default (cancel) rather than moderate as their security profile, but not to other platforms. Tying a bunch of unrelated security features together rather than just itemizing them causes a lot of confusion, especially when the security feature menus conflict with other menus that toggle the same features (enabling NFS specifically vs. having it turned back off again by sysinstall for a security profile). If we can expose this feature via rc.conf, just make it a seperate rc.conf entry and twiddle it off of the security configuration manu in sysinstall. Is that something we can do easily? 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.1020423205451.55944H-100000>