From owner-freebsd-hackers Tue Apr 23 20:35: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id D486A37B404; Tue, 23 Apr 2002 20:34:59 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3O3Ymw44575; Tue, 23 Apr 2002 23:34:48 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 23 Apr 2002 23:34:47 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Greg 'groggy' Lehey" Cc: Jordan Hubbard , Oscar Bonilla , Anthony Schneider , Mike Meyer , hackers@FreeBSD.org Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) In-Reply-To: <20020424125345.B50826@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: > > 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. The ssh issue is a bug. It has been fixed in -CURRENT, it should be fixed in -STABLE. It's not a sign of a bad trend in design, it should simply be changed. My disagreement with the solution was that the bug was being whacked in the wrong place: rather than fixing the bug, the suggested solution was to disable challenge response authentication entirely (?), or disable S/Key entirely. Neither resolved the real problem, especially if you want to use S/Key for some users, but not for all users. > > 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'm really unhappy with the idea of using securelevel for this. Securelevel if a kernel value that determines the outcome of a certain set of privileged operations, limiting root access. Well, modulo a little bit of abuse in the ipfilter code regarding a kernel callout, but it's arguable that really is abuse. This is a userland issue regarding socket binding choices by an application. > > 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. I'm not all that surprised to here that, but I'm not sure I know enough about the ports community to give direction there, other than to say "this needs fixing". > 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. I think securelevel is the wrong twiddle. If there aren't better twiddles, they can be created. Personally, I think a twiddle that reads: [X] Enable remote TCP-based access to X11 display, subject to normal X11 access control policy. would make much more sense than keying it to some general knob with diminished meaning. In particular, things like: [ ] Workstation security [ ] Secure workstation security [ ] Firewall security make little or no sense to anyone. I think the primary example of something that could use a better management tool is inetd.conf, but I'm not sure that's happening (see past threads on the topic). 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