Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Apr 2002 14:37:12 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        Terry Lambert <tlambert2@mindspring.com>
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:  <Pine.NEB.3.96L.1020423141144.64976l-100000@fledge.watson.org>
In-Reply-To: <3CC5A2D9.D9FB84A3@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Apr 2002, Terry Lambert wrote:

> Robert Watson wrote:
> > A more conservative default configuration results in a material
> > improvement in system security.
> 
> I really don't think there's any way to fully protect a
> security-unconscious user, as if they had spent the time to learn what
> was necessary, and chosen the right settings for their site.  Nothing
> can replace a system administrator who knows which end is up. 

I'll agree with the assertion that users unaware of a security threat, or
unwilling to address a threat, are hard to prevent from shooting
themselves in the feet.

> I think that trying to do this is doomed to failure, in that it will
> engender a false sense of security which is, in many cases, unwarranted
> and dangerous.  This is particularly true for FreeBSD, where the first
> thing anyone ever does with the system is install packages/ports which
> may themselves have undocumented security vulnerabilities (or even
> documented ones for which the documentation is ignored). 

"System programming is hard, let's go shopping".

Here I'll disagree with you: we make a concerted effort to produce a
system that is safe to use.  This involves a number of things, and it
doesn't just mean security fixes.  I would argue that we have a moral
obligation to do so.  Sure, we can't fix every port or package, but we do
actually make an effort to take a look through the more important/common
ones for obvious problems, and we are trying to move to architectures that
permit ports that have previously required privilege to run with less
privilege.  For example, one of the projects Thomas Moestl worked on on
the -CURRENT branch was to reduce the reliance on kmem access for system
monitoring tools.  The result is that base system tools (such as top) can
now often run without any extra privilege.  But a positive side effect is
that many non-base system tools can also run without privilege they
previously required. 

Someone who's unaware or unwilling to address security issues will *still*
be safer if we provide a safer system.  If they are going maliciously out
of their way, sure, there will be problems, but if they don't need telnet,
and we disable telnet by default, we have actually produced a safer system
for them.  And if they do need telnet, it's easy to turn on.

> This is particularly true when the system is running X11, as the system
> *never* *only* runs X11, but instead has all sorts of clients installed,
> as well, and generally a significant set of unaudited software, such as
> KDE, which you can attack via CORBA much easier than you could ever hope
> to directly attack an X11 server, whose defaults already do not permit
> remote connections through intrinsic access controls in the server
> ("xhost", et. al.). 

I think you've correctly identified an area where a lot of future security
work is needed.  However, that doesn't negate the need for security work
in the base system, because without a secure base system, you're building
everything else on sand.  If you have the time and resources to spend
helping to kick KDE and its related dependencies into shape, I welcome
your doing that.  It's something I haven't had time to work with yet, but
have definite future plans to do.

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.1020423141144.64976l-100000>