Date: Tue, 23 Apr 2002 23:34:47 -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.1020423232803.86817C-100000@fledge.watson.org> In-Reply-To: <20020424125345.B50826@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020423232803.86817C-100000>