Date: Wed, 24 Apr 2002 03:16:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Robert Watson <rwatson@FreeBSD.org> 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: <3CC6860B.17F10FBA@mindspring.com> References: <Pine.NEB.3.96L.1020423234154.64976o-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: > > 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. > > FWIW, the place where this should really go is the X11 configuration tool > -- if we extend the configurability of an application, the confuration > twiddles for that should live (and be documented) in the normal places for > that application, and not have any hooks of this sort in the base system. I really disagree with this. It's not an application level issue, it's a protocol level issue, and the knobs belong in the firewall management code, not in the per application code. It's really ridiculous that you can not set a policy for, for example, SMTP port exposure, unless you were to choose a particular MTA implementation, and set the policy in a per MTA configuration specific way. The X11 we are talking about here is not "the default X11", which is a set of distfiles, but a "ports" X11, which is not, but which is likely to be the basis of future distfiles. So we are really talking about an alternate set of code to provide or not provide the TCP "X11 display service". The thing that offended the hell out of everyone way that the decision was made for the future distfiles release (which is used by practically everyone) by sneaking it in the ports back door (which is used by practically no one), which, when viewed disparagingly, looks like an attempt to "pull a fast one". The policy and implementation *must* be seperated. > BTW, one really good reason not to tie securelevel and X11 behavior is > that securelevels (when high) specifically break X11, and likewise, other > management functionality that you might want to use with X11. Overloading > twiddles in this manner is a bad thing :-). THis is an implementation detail. Going to the GGI code for the FreeBSD console eliminates this breakage, by eliminating the need for the X11 server to obtain priviledges to access the hardware I/O and memory space without going through a non-data interface kernel abstraction. It's really not a fair comparison here, to point at secure level interference with X11 services, which are a result of a bad implementation choice. -- Terry 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?3CC6860B.17F10FBA>