Date: Tue, 23 Apr 2002 11:59:03 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Frank Mayhar <frank@exit.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.1020423113826.55944C-100000@fledge.watson.org> In-Reply-To: <200204231523.g3NFNQnq029649@realtime.exit.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Apr 2002, Frank Mayhar wrote: > Robert, it's really, really simple. For new installs, install the new, > more secure behavior. Be sure to loudly document this behavior so that > those of us who expect the _old_ behavior don't get bitten by the > change. And don't change the old behavior in upgrades of existing > systems. As I said in my other email, if you _must_ change the > defaults, add overrides so the behavior doesn't change. And by "add > overrides" I mean something like an /etc/rc.conf.override file that gets > pulled in after /etc/defaults/rc.conf but before /etc/rc.conf. And I'm saying that in general, we do this for the base system, but we don't have a formalized way of handling that for ports. I suggested that this be something the ports side of the camp needs to work on, perhaps in the form of explicit ports release notes for major ports/widely relevant changes. X11 currently falls into that category, although it doesn't for every system (for example, OpenBSD maintains X11 in-tree with a higher support level, as I understand it). However, I think it's not possible to argue for infinite backward compatibility during upgrades. One minor release is probably the limit of feasibility; major releases are probably not worth dealing with other than via documentation. For example, we make no effort to provide backward compatibility with /etc/sysconfig from the 2.x era. The right model is probably: - For rc.conf, provide limited backward compatibility (1 minor release) - For other configuration files (inetd.conf, for example), simply document the changes During binary upgrades, as well as source-based upgrades, we rely on the administrator to merge the majority of /etc configurations anyway: in general, no change gets made to /etc unless you explicitly perform it. Besides which, backwards compatibility isn't always possible, or desirable. When you upgrade to a new version, you assume that known security vulnerabilities in the old version will be remedied; you expect version increments on various libraries and utilities. This is in many ways no different than normal feature change, it just happens to have a specific motivation that we're generalizing about. > (This says nothing about the necessity or desirability of the change > itself, by the way. That's an entirely _different_ argument.) > > When you change defaults on a running system, you piss off a lot of > users. Including me. :-) When you change defaults on a running system, that's generally a specific administrative choice you've made. By upgrading the system, you accept that system behavior will change: in fact, you're asking for it to change! FreeBSD has some of the best updating/release notes in the open source space--certainly, more work can be done (especially in the area of ports, which is how this discussion started), but I think you don't want to take the "nothing changes, ever" philosophy too far. Upgrading a system accepts feature change--I don't think you'll find any vendor who will promise you that following an upgrade, things will be identical. Vendors focus system software upgrades on providing new feature sets, and providing a "consist" release. Most vendors provide a bumpier feature ride than we do, by virtue of not allowing such fine granularity with upgrades: we permit you to slide slowly forwards on -STABLE, rather than only providing major releases. But by taking advantage of finer granularity and greater access to the in-progress development work, you sacrifice some of the release engineering process. We do have branches that focus on minimal change: those are the release branches that pick up only critical security bugfixes. And even then, you may get feature change. So I'm not disagreeing with you -- I agree, backwards compatibility is important, and that includes the area of configuration files, and especially relating to the last relevant release number. Documentation should be our primary responsibility when it comes to changes, rather than an upgrade path that maintains identical behavior (which is probably not only impossible, but also undesirable). The documented behavior of rc.conf is that if you have a configuration line in there, it's probably paid attention to. If you rely on the system defaults, then when the defaults change, your system changes. If you want to know that a change in defaults won't affect your configuration, explicitly set the setting in rc.conf. We do try to provide compatibility here: for example, there are a number of things in 5.0 that will move from being rc.conf entries to just sysctl.conf entries. However, we're providing backwards compatibility for those settings for at least a minor release. 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.1020423113826.55944C-100000>