Date: Wed, 24 Apr 2002 12:53:45 +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: <20020424125345.B50826@wantadilla.lemis.com> In-Reply-To: <Pine.NEB.3.96L.1020423205451.55944H-100000@fledge.watson.org> References: <20020424090655.O6425@wantadilla.lemis.com> <Pine.NEB.3.96L.1020423205451.55944H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 23 April 2002 at 21:38:38 -0400, Robert Watson wrote: > > 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. Sorry, I wasn't trying to obfuscate anything. I was just trying to limit the message to a manageable length. It didn't come across too well, though. >>> - 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. Well, I see the "broader community" as the users. Now it's true that they don't have that much of a say, but what I'm seeing here is that very few people get to make these decisions. >>> "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. In this particular case, the subject line was meant ironically and was mainly intended to catch people's eyes. Until you mentioned it, it didn't occur in the text. > 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. Well, we saw the ssh problem as well; that's more than one. We also see things like rsh and rlogin die, maybe due to lack of love. I'm sure there are many more, some of which I have seen and accepted, others which I have seen and couldn't be bothered to complain, and others again that I haven't seen and that may or may not bite me in the future. The issue here is that the choice shouldn't be left to the individual if we're working as a team. > 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...) Well, what about checking securelevel before setting --nolisten-tcp? >> 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. No, that's only part of the issue, though it's an important one. I've had complaints from Apache people that we're not communicating back enough, for example. >> 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? I think the issue is POLA. Sure, we can put in individual knobs to twiddle, but who will do that? I thought that securelevel would have been a suitable solution to say "I want approximately *this* much security". If that's not the case, then we need a few generic statements which can then be further refined. 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?20020424125345.B50826>