Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Apr 2002 00:16:52 -0400
From:      Anthony Schneider <aschneid@mail.slc.edu>
To:        "Greg 'groggy' Lehey" <grog@FreeBSD.ORG>
Cc:        Jordan Hubbard <jkh@winston.freebsd.org>, Robert Watson <rwatson@FreeBSD.ORG>, Oscar Bonilla <obonilla@galileo.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:  <20020423001652.A15133@mail.slc.edu>
In-Reply-To: <20020423131646.I6425@wantadilla.lemis.com>; from grog@FreeBSD.ORG on Tue, Apr 23, 2002 at 01:16:46PM %2B0930
References:  <rwatson@FreeBSD.ORG> <Pine.NEB.3.96L.1020422223923.64976i-100000@fledge.watson.org> <11670.1019530386@winston.freebsd.org> <20020423131646.I6425@wantadilla.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
> be able to use it too.  I'd suggest that we do the following:
> 
> 1.  Give the user the choice of these additional features at
>     installation time.  Recommend the procedures, but explain that you
>     need to understand the differences.
> 
> 2.  Document these things very well.  Both this ssh change and the X
>     without TCP change are confusing.  If three core team members were
>     surprised, it's going to surprise the end user a whole lot more.
>     We should at least have had a HEADS UP, and we probably need a
>     security policy document with the distributions.
> 

I disagree somewhat with #1.  A "secure by default" policy is by far more
favorable than a "not so secure by default, but we'll try to let you know
how to make it more secure easily" policy.  Consider a move to make telnetd
commented out in inetd.conf a default.  Many newcomers will of course be
baffled, but it is in the long run a better policy, and people will get 
used to it.  

This example is somewhat of an *extremely* simplified analogy to adding
s/key authentication as a default before password authentication, but it 
still holds in that a default installation had better be more secure than 
not.  If FreeBSD were to have installation dialogues with the user 
suggesting that the user install certain components for security purposes, 
the user will likely opt for the default "button," which I assume in this 
case would default to have the less secure, more conventional option.  

I think that #2 alone is the way to go.  Make it "clear" (not that that 
is necessarily an easy task) that the default install of a certain 
software package no longer follows what has historically been the default, 
or at least do so in the case where the software will become unusable to 
the unknowing user.

Perhaps a "SEVERE DIFFERENCES" section of www.freebsd.org is in order? 8D

-Anthony.

> 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
-----------------------------------------------
PGP key at:
    http://www.keyserver.net/
    http://www.anthonydotcom.com/gpgkey/key.txt
Home:
    http://www.anthonydotcom.com
-----------------------------------------------


[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjzE4DQACgkQ+rDjkNht5F3VWgCcD9tLXsA+FtswntwgvJVjCtTt
Mb0An0mzxR1HpObecoV7wTi+Q8DJgEj/
=hzuW
-----END PGP SIGNATURE-----

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020423001652.A15133>