FreeBSD: Secure By Default, Or Secure By Obscurity?

A recent thread on the FreeBSD hackers mailing list began when Jordan Hubbard reported odd behavior with ssh in the 4.5-STABLE tree. The change in behavior was due to a change in the default setting in the interests of security. During the dicussion another change to default behavior was brought up where X11 now has TCP forwarding disabled, prefering instead that the users tunnel X connections through ssh.

Much of the resulting protest was at how this changes FreeBSD's default behavior, creating confusion. Joerg Micheel said, "The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century."

The attempt is to make the default installation more secure. Terry Lambert points out, "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."

Finally, as the conversation considered whether such changes were security by obscurity, Robert Watson offered, ""Security by obscurity" refers to a behavioral phenomena in system design and delivery, not to a technical design principle. For example, it refers to using a secret algorithm, but does not refer to using a secret key with a published algorithm. So disabling services in a default configuration reduces risk by reducing exposure, but it's not security by obscurity. "

From: Jordan Hubbard To: hackers AT FreeBSD.ORG Subject: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 17:39:26 -0700 (PDT) We at Apple are noticing a strange problem with newer versions of ssh (which has been upgraded to OpenSSH_3.1p1) and FreeBSD 4.5-STABLE's sshd. This problem did not occur with our older ssh, but it also does not occur with the newer version and *any* other OS other than FreeBSD, e.g. if you ssh to a Linux or Solaris or Mac OS X box, for that matter, you will not see this behavior. What behavior am I talking about? This: jhubbard@wafer-> ssh jkh@winston.freebsd.org otp-md5 114 wi7854 ext S/Key Password: otp-md5 117 wi5044 ext S/Key Password: otp-md5 397 wi0652 ext S/Key Password: jkh@winston.freebsd.org's password: The machine "wafer" is a Mac OS X box running 10.1.3 and winston.freebsd.org is running FreeBSD 4.5-STABLE. The authentication method which tries this S/Key stuff is "keyboard-interactive" and this is tried, for some reason, before the "password" auth method. If you compile sshd on the FreeBSD side without SKEY support built-in, the problem also goes away. My question: Who's "wrong" here, FreeBSD or Mac OS X? If the latter, why doesn't Linux or anything else produce this problem? I ask now because I know that the usage of Mac OS X is growing and there are going to be a lot of annoyed users (like me!) who very quickly get tired of having to wind through all the bogus S/Key password prompts before they can actually type in their real password (and no, skey is not enabled on winston and I have never done a keyinit operation, so I couldn't S/Key authenticate to it if I wanted to). - Jordan From: Josef Karthauser Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Tue, 23 Apr 2002 01:45:04 +0100 I got it sshing from -current to a freshly installed 4.5 box and it continued to happen when I upgraded the 4.5 box to 5.0-DP1. It doesn't happen when I ssh to my regular -stable server, but I've not investigated the reasons why. Joe From: Mike Meyer Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 20:04:43 -0500 Someone decided that FreeBSD should do challenge-response authentication by default. You can fix it by uncommenting the line "#ChallengeResponseAuthentication no" in /etc/ssh/sshd_config. From: Anthony Schneider Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 21:41:20 -0400 that's what fixxed it for me, too. SkeyAuthentication no also does it. :) -Anthony. From: Oscar Bonilla Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 19:44:41 -0600 shouldn't the default be no skey? From: Jordan Hubbard Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 19:01:21 -0700 That would be my question as well, especially since "everyone else" seems to use that default. Thanks to all who responded, and so quickly at that - this at least clarified the situation (and gave me a way out!). - Jordan From: Robert Watson Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 22:41:02 -0400 (EDT) This was discussed fairly extensively regarding -current: basically, s/key is "greedy" and attempts to fake s/key responses even for users who don't have s/key enabled. Nothing is wrong with challenge response -- arguably, that's a cleaner way to handle things as a default in the client, since it means if you connect to a server that does want to use challenge response, it DTRT. The fix in -CURRENT, I believe, was to make s/key "faking" for non-enabled users be an option, and to turn the option off by default. That fix relies on the extensive PAM updates in -CURRENT however; in -STABLE it can probably be similarly replicated via appropriate tweaking of sshd (?). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [email blocked] NAI Labs, Safeport Network Services From: Jordan Hubbard Subject: Re: ssh + compiled-in SKEY support considered harmful? Date: Mon, 22 Apr 2002 19:53:06 -0700 Why not fix it in stable by the very simple tweaking of the ChallengeResponseAuthentication to no in the sshd config file we ship Trust me, this question is going to come up a _lot_ for us otherwise. :( - Jordan From: Greg 'groggy' Lehey Subject: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) Date: Tue, 23 Apr 2002 13:16:46 +0930 I've been noticing a continuing trend for more and more "safe" configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to 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. Greg From: Anthony Schneider Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) Date: Tue, 23 Apr 2002 00:16:52 -0400 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.

From: Bruce A. Mah Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) Date: Mon, 22 Apr 2002 21:52:28 -0700 [CC list trimmed] If memory serves me right, "Greg 'groggy' Lehey" wrote: > 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. The SSH change happened before 4.5-RELEASE, but wasn't documented. I admit to having been totally unaware of this change at the time. green and I made several attempts at an item for the errata, which, while not perfect, does give some workarounds for the problem, including almost every one mentioned in this thread. So far, it looks like precious few people on this thread actually read it. :-( > We should at least have had a HEADS UP, Having run into the SSH change myself, I agree. I haven't bumped into the "X without TCP" change. > and we probably need a > security policy document with the distributions. Hmmm. Still trying to wrap my mind around this concept, but I'm worried that people won't read *that* document either. In any case, someone needs to maintain it to make sure it doesn't get stale. Cheers,

From: Jochem Kossen Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?) Date: Tue, 23 Apr 2002 10:09:51 +0200 > I've been noticing a continuing trend for more and more "safe" > configurations the default. I spent half a day recently trying to > find why I could no longer open windows on my X display, only to > discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind:

       Except for the '-listen_tcp' option, arguments immediately
       following the startx command are used to start a client in
       the  same manner as xinit(1).  The '-listen_tcp' option of
       startx enables the TCP/IP transport type which  is  needed
       for  remote  X  displays.  This is disabled by default for
       security reasons.

> I have a problem with this, and as you imply, so will a lot of other
> people. As a result of this sort of thing, people trying to migrate
> from other systems will probably just give up. I certainly would
> have. While it's a laudable aim to have a secure system, you have to
> 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'd agree with option 2. Except that people trying to use X with tcp
connections probably won't look in the security policy document for a
solution. In the case of the X patch, i'd add it to the release notes
AND the security policy document, since - i think - few people will
look in the security policy document for such a problem.

I do have to say you're the first one I see who complains about this...

Jochem
Bruce.

From: Robert Watson
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 11:59:03 -0400 (EDT)

On Tue, 23 Apr 2002, Frank Mayhar wrote:

> Robert, it's really, really simple. For new installs, install the new,
> more secure behavior. Be sure to loudly document this behavior so that
> those of us who expect the _old_ behavior don't get bitten by the
> change. And don't change the old behavior in upgrades of existing
> systems. As I said in my other email, if you _must_ change the
> defaults, add overrides so the behavior doesn't change. And by "add
> overrides" I mean something like an /etc/rc.conf.override file that gets
> pulled in after /etc/defaults/rc.conf but before /etc/rc.conf.

And I'm saying that in general, we do this for the base system, but we
don't have a formalized way of handling that for ports. I suggested that
this be something the ports side of the camp needs to work on, perhaps in
the form of explicit ports release notes for major ports/widely relevant
changes. X11 currently falls into that category, although it doesn't for
every system (for example, OpenBSD maintains X11 in-tree with a higher
support level, as I understand it).

However, I think it's not possible to argue for infinite backward
compatibility during upgrades. One minor release is probably the limit of
feasibility; major releases are probably not worth dealing with other than
via documentation. For example, we make no effort to provide backward
compatibility with /etc/sysconfig from the 2.x era. The right model is
probably:

- For rc.conf, provide limited backward compatibility (1 minor release)

- For other configuration files (inetd.conf, for example), simply document
the changes

During binary upgrades, as well as source-based upgrades, we rely on the
administrator to merge the majority of /etc configurations anyway: in
general, no change gets made to /etc unless you explicitly perform it.

Besides which, backwards compatibility isn't always possible, or
desirable. When you upgrade to a new version, you assume that known
security vulnerabilities in the old version will be remedied; you expect
version increments on various libraries and utilities. This is in many
ways no different than normal feature change, it just happens to have a
specific motivation that we're generalizing about.

> (This says nothing about the necessity or desirability of the change
> itself, by the way. That's an entirely _different_ argument.)
>
> When you change defaults on a running system, you piss off a lot of
> users. Including me. :-)

When you change defaults on a running system, that's generally a specific
administrative choice you've made. By upgrading the system, you accept
that system behavior will change: in fact, you're asking for it to change!
FreeBSD has some of the best updating/release notes in the open source
space--certainly, more work can be done (especially in the area of ports,
which is how this discussion started), but I think you don't want to take
the "nothing changes, ever" philosophy too far. Upgrading a system
accepts feature change--I don't think you'll find any vendor who will
promise you that following an upgrade, things will be identical. Vendors
focus system software upgrades on providing new feature sets, and
providing a "consist" release. Most vendors provide a bumpier feature
ride than we do, by virtue of not allowing such fine granularity with
upgrades: we permit you to slide slowly forwards on -STABLE, rather than
only providing major releases. But by taking advantage of finer
granularity and greater access to the in-progress development work, you
sacrifice some of the release engineering process.

We do have branches that focus on minimal change: those are the release
branches that pick up only critical security bugfixes. And even then, you
may get feature change.

So I'm not disagreeing with you -- I agree, backwards compatibility is
important, and that includes the area of configuration files, and
especially relating to the last relevant release number. Documentation
should be our primary responsibility when it comes to changes, rather than
an upgrade path that maintains identical behavior (which is probably not
only impossible, but also undesirable). The documented behavior of
rc.conf is that if you have a configuration line in there, it's probably
paid attention to. If you rely on the system defaults, then when the
defaults change, your system changes. If you want to know that a change
in defaults won't affect your configuration, explicitly set the setting in
rc.conf. We do try to provide compatibility here: for example, there are
a number of things in 5.0 that will move from being rc.conf entries to
just sysctl.conf entries. However, we're providing backwards
compatibility for those settings for at least a minor release.

From: Terry Lambert
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 11:07:21 -0700

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 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).

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.).

-- Terry

From: Robert Watson
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 14:37:12 -0400 (EDT)

On Tue, 23 Apr 2002, Terry Lambert wrote:
> 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.

To: Robert Watson
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 11:56:46 -0700

Robert Watson wrote:
> "System programming is hard, let's go shopping".

This is exactly the phrase that comes to mind every time someone
yanks the plug on a service they are afraid might one day have
an exploit found for it.

> 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.

"Securing telnet is hard; let's turn it off and go shopping". 8-).

> 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.

No one has *that* much time. Auditing that code base would be on
the order of the difficulty of auditing Windows, and we have the
source code the KDE.

I agree that the base system needs to be secure, but I think you
either trust your security model, or you don't: X11 *does* have a
security model, even if it doesn't encrypt all the traffic over
all its connections by default. If the security model is flawed,
then it needs to be fixed, not turned off.

I think it's a lot worse to leave a vulnerable telnetd turned off
by default but available to be turned on, than to have one that's
non-vulnerable turned on by default.

The fear that someone is going to find a vulnerability should be
balanced by the idea that someone is going to fix it, not balanced
by the idea that that you can hide the vulnerability by not running
the vulnerable code, "mostly".

I guess this is a basica philosophical difference: IMO, exposure
equals the probability of a fix. Turning things off belongs in
the firewall code.

FWIW: I wouldn't object to a firewall rule that disallowed remote
TCP connections to the X server by default, if the firewall is
enabled. I think we already have this...

-- Terry

From: Frank Mayhar
Subject: More about security, X, rc.conf and changing defaults.
Date: Tue, 23 Apr 2002 12:53:56 -0700 (PDT)

Terry Lambert wrote:
> FWIW: I wouldn't object to a firewall rule that disallowed remote
> TCP connections to the X server by default, if the firewall is
> enabled. I think we already have this...

Yep, I agree, and whether or not it's in the distributed rc.firewall, I
have the ports blocked in my hand-tuned version.

As to Stijn's remarks, he is putting up a strawman at best. If a person
runs X, it should be their responsibility to make sure that it's secure.
Just like if they ran Windows or any other software with potential security
holes. X is plastered with warnings as it is, why do we need to cripple a
function it supports? Stijn, if it "opens up a hole in your network,"
that's _your_ problem, not mine. There are many other ways to secure your
network than by turning off tcp connections by default in the X server.
Hey, I'm not objecting to adding the capability, I'm just objecting to
the fact that it was imposed upon everyone else by fiat and (worse) without
warning.

And before people start saying again that this only affects a port and is
irrelevant to the operating system itself, this is one symptom of what I
see as a worsening problem. I agree with Warner that the former default
should only be supported until the next major release, but that former
default _should be supported_. Yeah, it's up to me as a sysadmin to notice
this stuff and fix it, but how many people pay that much attention to the
stuff in /etc/defaults when they are in the middle of upgrading a bread-and-
butter system (to get it closer to the current -stable, so later improvements
won't be so difficult to bring in) and are going as fast as they can? Much
better, IMNSHO, to create the new /etc/rc.override (or whatever) script and
let it bug the admin about the fact that the defaults have changed. And _not_
spring this sort of thing on the FreeBSD world unawares.

Not all of us have time to pay attention to the mailing lists (or even _one_
of the mailing lists) to catch this sort of thing before it gets committed.

Hey, I'm a software engineer for Wind River (with a fulltime job there),
plus sole engineer and sysadmin for my own side business. I barely have
time for _sleep_.

From: Robert Watson
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 17:31:05 -0400 (EDT)

On Tue, 23 Apr 2002, Terry Lambert wrote:
> This is exactly the phrase that comes to mind every time someone yanks
> the plug on a service they are afraid might one day have an exploit
> found for it.

This isn't about yanking services based on blind speculation; this is
about managing risk. We ship a system that has a "moderate" risk
trade-off: we focus efforts on reducing risk in two ways. First, we
evaluate the risk of components of the system, and focus security
development efforts on improving those areas. Second, we evaluate the
risk of these same components, and select system defaults in a manner that
selects a reasonable balance of service and risk. This is why we've made
the following classes of changes:

- Changes to address specific known vulnerabilities (performed in a
cooperative manner between the security-officer and the broader
developer community)
- Changes to reduce the privilege level required for management and
monitoring applications (largely present in 5.0)
- Re-implementation of core authentication components that were previously
poorly integrated (PAM, ...)
- Investment in improved network stack safety and firewall implementation
(DARPA/NAI Labs have a contract with Jonathan Lemon that includes time
spent specifically on investigating risks in the IP stack, and reducing
them). There's also contract work to Jonathan Lemon to implement
improved network crypto hardware integration, which he has a prototype
of and will hopefully post when he's back from his current hiatus.
- Evaluation of the focus of past vulnerabilities, including their source
in the system code, the criticallity of the vulnerability, and the
exposure associated with each vulnerability. This includes some time
spent looking at how quickly various sorts of vulnerabilities tend to
occur following releases, etc.
- Investment in new policies and architectures improving flexibility for
the administrator.

Security is an area of active development in the FreeBSD Project, and we
seem to have a strong grasp of a number of areas of the field.

> "Securing telnet is hard; let's turn it off and go shopping". 8-).

Or maybe,

Few people use telnet any more, so we'll spend some time fixing it, but
we'll also disable it by default, since many of the reports of
compromise come from people who weren't even using it, but left it
turned on since it was the default.

> No one has *that* much time. Auditing that code base would be on the
> order of the difficulty of auditing Windows, and we have the source code
> the KDE.

Certainly an in depth audit of something with the size and complexity of
KDE will be a challenge; however, there's a lot of work that can be done
without doing it line-by-line.

> I agree that the base system needs to be secure, but I think you either
> trust your security model, or you don't: X11 *does* have a security
> model, even if it doesn't encrypt all the traffic over all its
> connections by default. If the security model is flawed, then it needs
> to be fixed, not turned off.

Security models and vulnerabilities aren't necessarily related issues.
Sure, a good model helps in the event there is a vulnerability, but having
a good model doesn't mean you'll be invulnerable to implementation flaws,
flaws in the model, etc. Personally, I had nothing to do with the choice
to turn off X11, but with it now changed, I'm happy with the change.
Personally, I'd recommend using SSH and letting it take care of the
details.

> I think it's a lot worse to leave a vulnerable telnetd turned off by
> default but available to be turned on, than to have one that's
> non-vulnerable turned on by default.

Yeah, the great thing about vulnerabilities is that if you knew they were
there you would most likely have fixed them before you released the
product. Conservative defaults help you with risk you believe is present,
but where you can't necessarily make the material improvement that you'd
like to. In the case of telnetd, we accept that the risk exists, we
attempt to improve the software, but because it's less and less frequently
used and represents an attack channel for a variety of attacks, we disable
it by default, but provide an easy way to re-enable it.

> The fear that someone is going to find a vulnerability should be
> balanced by the idea that someone is going to fix it, not balanced by
> the idea that that you can hide the vulnerability by not running the
> vulnerable code, "mostly".

The reality is that reducing exposure is an important part of any security
posture. Any additional exposure increases risk, no matter how minutely.
If handled carefully, the risk of vulnerability are low: the chances are
small one would be found, and/or the effects of the vulnerability may be
contained. However, services that provide full authentication and
credential management (such as telnetd) do badly on both fronts: the
complexity and age of the code is high, and the involvement of the code in
security subsystems is high. The accepted practice in the security
community is to disable services presenting risk until they are necessary.
The practical mapping of such a policy into FreeBSD is that inetd might be
on by default, but all services in it would be disabled by default.
Services would then be selectively enabled as they are needed. This is
what happens in 5.0-CURRENT; recently there was some discussion regarding
whether an MFC was appropriate, but I'm not sure that has worked itself
out yet. 5.0-RELEASE will represent a good breaking point for that kind
of change.

> I guess this is a basica philosophical difference: IMO, exposure equals
> the probability of a fix. Turning things off belongs in the firewall
> code.

In my opinion, we should focus both on reducing exposure and improving the
code. I personally have tried to impact both sides of the balance, and
would encourage others to do so also :-).

> FWIW: I wouldn't object to a firewall rule that disallowed remote TCP
> connections to the X server by default, if the firewall is enabled. I
> think we already have this...

The firewall code serves a useful function, but one of its great
detriments is a lack of application awareness. The current placement of
the policy seems most reasonable to me, but might be supplemented by such
a rule if desired.

From: Terry Lambert
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 16:56:43 -0700

Robert Watson wrote:
> Few people use telnet any more, so we'll spend some time fixing it, but
> we'll also disable it by default, since many of the reports of
> compromise come from people who weren't even using it, but left it
> turned on since it was the default.

"Few people will use telnet, particularly after we turn it off and
go shopping. We can avoid vulnerability reports by reducing the
number of systems running the code."

8-) 8-) 8-).

From: Robert Watson
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 21:44:27 -0400 (EDT)

On Tue, 23 Apr 2002, Terry Lambert wrote:

> This is an argument for security through obscurity.
>
> If we are talking risk reduction, then we can easily achieve it
> statistically through obscurity. In fact, this is exactly what FreeBSD
> does through its choice of TCP sequence numbers.

"Security by obscurity" refers to a behavioral phenomena in system design
and delivery, not to a technical design principle. For example, it refers
to using a secret algorithm, but does not refer to using a secret key with
a published algorithm. So disabling services in a default configuration
reduces risk by reducing exposure, but it's not security by obscurity.

When shipping third party code, or our own code, we accept that some code
is more at risk than other code. That risk might be the result of
complexity, privilege, exposure, ... Whatever the reason, it's
disingenuous to sweep it under the rug ("all our code is good, so we ship
it all turned on") rather than select safe defaults and let people turn on
what they need.

> Application state is not necessary for incoming connections which are
> self-identified by source and destination IP and port; the existing
> stateless firewall code can handle them completely, without introducing
> problems.

X arguments that disable the X11 protocol over TCP will work regardless of
the configured TCP port for XFree86. Firewall rules won't. Also,
firewall rules may interfere with other applications, where X11
configuration won't. Both have their place.

> Actually, it would be more useful to concentrate on so-called "stealth
> firewall" technology, so that OS identification due to port scans, etc.,
> is impossible, and so it looks as if there is no machine there
> whatsoever, if there are no services actively listening AND access is
> permitted to the source machine.

No doubt an interesting area to explore.

From: Terry Lambert
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Wed, 24 Apr 2002 02:48:14 -0700

Robert Watson wrote:
> "Security by obscurity" refers to a behavioral phenomena in system design
> and delivery, not to a technical design principle. For example, it refers
> to using a secret algorithm, but does not refer to using a secret key with
> a published algorithm. So disabling services in a default configuration
> reduces risk by reducing exposure, but it's not security by obscurity.

However, if the goal is risk reduction, then "security by
obscurity" arguably reduces risk.

> When shipping third party code, or our own code, we accept that some code
> is more at risk than other code. That risk might be the result of
> complexity, privilege, exposure, ... Whatever the reason, it's
> disingenuous to sweep it under the rug ("all our code is good, so we ship
> it all turned on") rather than select safe defaults and let people turn on
> what they need.

This somewhat drops us into the "What is UNIX?" argument. I
don't think you want to go there.

> X arguments that disable the X11 protocol over TCP will work regardless of
> the configured TCP port for XFree86. Firewall rules won't. Also,
> firewall rules may interfere with other applications, where X11
> configuration won't. Both have their place.

I can run sendmail on another port as well. At some point, you
have to accept that there are Schelling points where policy and
implementation can rendesvous. It's not reasonable to argue that
an external mechanism is unusable because someone *might* start
X11 with a different port. They *might* start it with the argument
that reenables TCP. The coupling argument you are making here is
specious: the default model for firewall protection is "disable
everything by default, and enable only that which is explicitly
permitted".

The point is that there is already a model for TCP service protection,
and adding another frob on the side of each server for it really
obfuscates the application of a uniform model to the problem.

If we grant for a moment your argment "complexity := vulnerability",
then this increase of complexity is a problem, isn't it?

> No doubt an interesting area to explore.

Mostly, it boils down to dropping packets instead of sending RSTs
or ACKs.

-- Terry

From: Greg 'groggy' Lehey
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 18:34:52 +0930

> A simple 'man startx' should have cleared your mind:

Well, yes. But I've been using X for 11 years. Why should I have to
read the man page to find changes? How do I know which man page to
read? If I did that for everything that happened, I wouldn't get any
work done. And you can bet your bottom dollar that somebody coming
from another UNIX variant and trying out FreeBSD won't do so. They'll
just say that it's broken and wander off again.

> I'd agree with option 2. Except that people trying to use X with tcp
> connections probably won't look in the security policy document for a
> solution.

Correct. That's why I think option 1 is preferable.

> In the case of the X patch, i'd add it to the release notes AND the
> security policy document, since - i think - few people will look in
> the security policy document for such a problem.

I think it shouldn't happen at all unless people agree to it.

> I do have to say you're the first one I see who complains about
> this...

Maybe the others have given up.

But since we're on the subject, why? What's so insecure about X TCP
connections? Until you explicitly allow connections, the only system
that can open the server is the local system.

From: Joerg Micheel
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 21:13:59 +1200

On Tue, Apr 23, 2002 at 06:34:52PM +0930, Greg 'groggy' Lehey wrote:
> Well, yes. But I've been using X for 11 years. Why should I have to
> read the man page to find changes? How do I know which man page to
> read? If I did that for everything that happened, I wouldn't get any
> work done. And you can bet your bottom dollar that somebody coming
> from another UNIX variant and trying out FreeBSD won't do so. They'll
> just say that it's broken and wander off again.

FWIW, I would be extremly pissed about this myself, I just happen to
not having installed 4.5 myself yet, for other reasons. I thought there
was a policy of the least surprise, it might have been to kernel code,
but should be applied here as well.

The system has to work right away, when installed out of the box. Period.
No when's and if's. And don't tell me that X11 is an add-on and luxury.
We are living in the 21st century.

Joerg

From: Neil Blakey-Milner
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 11:38:26 +0200

On Tue 2002-04-23 (21:13), Joerg Micheel wrote:
> The system has to work right away, when installed out of the box. Period.
> No when's and if's. And don't tell me that X11 is an add-on and luxury.
> We are living in the 21st century.

There are people who will tell people that still use X11 tcp sockets to
start living in the 21st century. ssh X11 forwarding still works, it's
only the (often much lower security) tcp sockets that are disabled by
default. (And if the "none" cipher is available, the overhead would be
minimal for even the most underpowered machine.)

At least Debian takes this stance, and so many believe it's a sane
default. If it were reverted, I'm sure there'll be lots of people
re-adding the change to their security regimen. And lots more people
scurrying to patch when the next DoS or exploit comes out.

Neil

From: Joerg Micheel
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 22:20:58 +1200

I may not understand all the issues here, but can the situation be
helped by improving the reporting. I.e. if the firewalling prohibits
access to the X11 TCP socket, why would the firewall not report this
instantly at the first attempt to connect, to be visible at the console
and in /var/log/messages. I am sure Greg would have caught that first
time around, and it would have safed him from a few hours of useless
debugging time.

Joerg

From: Marco Molteni
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 12:22:31 +0200

On Tue, 23 Apr 2002 11:38:26 +0200, Neil Blakey-Milner wrote:

> There are people who will tell people that still use X11 tcp sockets to
> start living in the 21st century. ssh X11 forwarding still works, it's
> only the (often much lower security) tcp sockets that are disabled by
> default. (And if the "none" cipher is available, the overhead would be
> minimal for even the most underpowered machine.)

I completely agree with Neil. Being scared by X11 access mechanisms, I
always disabled the TCP listen of the X server, and I always used ssh
with X forwarding.

marco

From: Terry Lambert
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 03:48:23 -0700

Neil Blakey-Milner wrote:
> There are people who will tell people that still use X11 tcp sockets to
> start living in the 21st century. ssh X11 forwarding still works, it's
> only the (often much lower security) tcp sockets that are disabled by
> default. (And if the "none" cipher is available, the overhead would be
> minimal for even the most underpowered machine.)

I agree that X11 isn't very forward looking; it'd be nice if
the displays were themselves CORBA objects, so you could
embed desktops to use any display technology you wanted, so
that you could build a desktop compute server for 1000 users
without eating 11G of RAM to do it.

Until someone writes that though...

It's be nice if the ssh X11 forwarding were not the prefered
method of remote access to X11. Particularly since I haven't
seen any fixes for the MIT shared memory extension going in to
stop the inevitable shared memory leaks by Netscape, etc., or
anything else that uses it for bitmaps, and is long running, so
the resources get used up and never reclaimed.

Disabling the workaround -- which is to use network connections,
instead of using the UNIX domain socket, thereby disabling the
libraries use of the shared memory extension -- isn't my idea of
a good approach. All it does is exacerbate the problem, for
questionable security ("not listening" is not the same thing as
having a firewall, so if TCP is vulnerable for X11, then it's
vulnerable for every other port that *is* listening).

Forget Debian, what does OpenBSD do? It's the gold standard
when it comes to anal default settings.

-- Terry

From: Jochem Kossen
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 12:13:00 +0200

On Tuesday 23 April 2002 11:13, you wrote:
> FWIW, I would be extremly pissed about this myself, I just happen to
> not having installed 4.5 myself yet, for other reasons. I thought
> there was a policy of the least surprise, it might have been to
> kernel code, but should be applied here as well.

I haven't seen your complaint anywhere...

> The system has to work right away, when installed out of the box.
> Period. No when's and if's.

It does work. But i think you mean the tcp connections.
Does that mean you vote for enabling _all_ services? They don't work out
of the box as well...

> And don't tell me that X11 is an add-on and luxury.

I agree, but the tcp connections IS an add-on luxury imho

> We are living in the 21st century.

That's right, the century of virii, DoS attacks, worms, and
scriptkiddiots.

From: Frank Mayhar
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 07:57:19 -0700 (PDT)

Jochem Kossen wrote:
> It does work. But i think you mean the tcp connections.
> Does that mean you vote for enabling _all_ services? They don't work out
> of the box as well...

This is ridiculous. You know as well as I do that that's _not_ what Greg
means. Just don't change stuff out from under the users.

> > And don't tell me that X11 is an add-on and luxury.
> I agree, but the tcp connections IS an add-on luxury imho

Wrong. It's the way it works.

> > We are living in the 21st century.
> That's right, the century of virii, DoS attacks, worms, and
> scriptkiddiots.

Then fix the security holes at your end and leave the rest of to fix
them the way _we_ want to. Don't impose your "fix" on the rest of us
by fiat.

From: Jochem Kossen
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 18:48:48 +0200

On Tuesday 23 April 2002 16:57, Frank Mayhar wrote:
> This is ridiculous. You know as well as I do that that's _not_ what
> Greg means. Just don't change stuff out from under the users.

True, but this mail wasn't a response to Greg. Over the time i've used
FreeBSD, i've seen several services been disabled by default, and i
don't see a difference between that and this. Care to explain?

> > > And don't tell me that X11 is an add-on and luxury.
> >
> > I agree, but the tcp connections IS an add-on luxury imho
>
> Wrong. It's the way it works.

Yup, and i didn't like the way it works

> > > We are living in the 21st century.
> >
> > That's right, the century of virii, DoS attacks, worms, and
> > scriptkiddiots.
>
> Then fix the security holes at your end and leave the rest of to fix
> them the way _we_ want to. Don't impose your "fix" on the rest of us
> by fiat.

Excuse me? I thought i sent in a patch which was an improvement. The
people responsible thought so too. The patch was a proposal, nothing
more, nothing less. I don't care at all wether my patch is in the ports
or not, i just thought it was a good idea, so i sent it in. I see
nothing wrong in that.

If people disagree with the patch, send in a PR and/or remove the patch.
That's all there is to it. The patch lives at
x11/XFree86-4-libraries/files/patch-startx

From: Jochem Kossen
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 12:06:01 +0200

On Tuesday 23 April 2002 11:04, you wrote:
> > A simple 'man startx' should have cleared your mind:
>
> Well, yes. But I've been using X for 11 years. Why should I have to
> read the man page to find changes?

Because things evolve? :)

> How do I know which man page to read?

You start X with startx, seems obvious to me. The disabling of tcp
connections only applies to startx

> If I did that for everything that happened, I wouldn't get any
> work done. And you can bet your bottom dollar that somebody coming
> from another UNIX variant and trying out FreeBSD won't do so.

OK, then i suggest we mention it in the handbook, the security policy
document, the manpage AND the release notes :)

> > I'd agree with option 2. Except that people trying to use X with
> > tcp connections probably won't look in the security policy document
> > for a solution.
>
> Correct. That's why I think option 1 is preferable.

I was trying to say to not just notify it in the security policy alone.

> > In the case of the X patch, i'd add it to the release notes AND the
> > security policy document, since - i think - few people will look in
> > the security policy document for such a problem.
>
> I think it shouldn't happen at all unless people agree to it.

3 people did, 0 people did not...read below

> > I do have to say you're the first one I see who complains about
> > this...
>
> Maybe the others have given up.

LOL

> But since we're on the subject, why? What's so insecure about X TCP
> connections? Until you explicitly allow connections, the only system
> that can open the server is the local system.

For the simple reason I don't like useless open ports on my system. I
don't use it, _most_ other people don't use it, so i sent in a patch.

Peter Pentchev liked the idea, Jean-Marc Zucconi (the maintainer) didn't
have any objections, and when I showed the patch to Will Andrews when
he was busy with the meta port, he liked it too and integrated it. I
haven't seen any other reactions to it.

Of course, it was only discussed on the ports@ mailinglist, but it
didn't seem like such a big deal to me or apparently the others...

Jochem

From: Frank Mayhar
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Tue, 23 Apr 2002 07:54:59 -0700 (PDT)

Jochem Kossen wrote:
> Because things evolve? :)

You say "evolve." I say "get broken."

> > How do I know which man page to read?
> You start X with startx, seems obvious to me. The disabling of tcp
> connections only applies to startx

It's not obvious when one has been starting X with the same command for
years and it has never before changed. Gee, seems to seriously violate
POLA, eh?

> OK, then i suggest we mention it in the handbook, the security policy
> document, the manpage AND the release notes :)

Just don't do it in the first place. If you must have this, make a _new_
command ("secure-startx," perhaps) and point to it in the release notes.

> For the simple reason I don't like useless open ports on my system. I
> don't use it, _most_ other people don't use it, so i sent in a patch.

Yeah, but unless one is installing a fresh system, one shouldn't care so
much. And, by the way, how do you define "useless?" To me, having X
listening for TCP connections is far from useless.

> Of course, it was only discussed on the ports@ mailinglist, but it
> didn't seem like such a big deal to me or apparently the others...

This is another case of changing the default in such a way as to violate
POLA.

I've given this some thought, particularly with respect to the rc.conf
changes. My opinion is that, while this kind of thing is a good idea
for from-scratch installs (the kind a person new to FreeBSD might be
doing), making these changes to a running system is a Really Bad Idea.
That means that if you _must_ change the defaults, add overrides at
the same time to maintain the old default behavior. Then document the
hell out of the new defaults. One shouldn't have to read ancient
mail archives or pore over cvs logs to figure out what happened and
why.

Hey, I'm a kernel programmer (I work on BSD/OS as it happens). I know
what it's like to be stuck with obsolete defaults. The fact of the
matter is, though, that if I change a default and that upsets our
customers, we potentially lose revenue and I potentially lose my job.
This gives me real incentive to get it right, and that means not pulling
the rug out from under the end user.

IMHO, this was botched. Sorry, David, I calls 'em as I see 'em.

From: Jochem Kossen
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Tue, 23 Apr 2002 18:39:44 +0200

On Tuesday 23 April 2002 16:54, Frank Mayhar wrote:
> You say "evolve." I say "get broken."

Don't tell me that in 11 years, defaults never change

> It's not obvious when one has been starting X with the same command
> for years and it has never before changed. Gee, seems to seriously
> violate POLA, eh?

I agree, but i still wonder why people didn't come up with it sooner

> Just don't do it in the first place. If you must have this, make a
> _new_ command ("secure-startx," perhaps) and point to it in the
> release notes.

This is a very good idea IMHO, although without the patch 'startx
-nolisten_tcp' works too...Then i'd say rip the patch out completely

> Yeah, but unless one is installing a fresh system, one shouldn't care
> so much. And, by the way, how do you define "useless?" To me,
> having X listening for TCP connections is far from useless.

It is useless to _me_ because i don't use it. Like i said in a previous
mail, I didn't like the default, so I sent in the patch as a proposal
to the ports@ mailinglist, and they all seemed to like it too. Nobody
complained, thus the patch was integrated. Simple.

I sent in the patch because it seemed obvious to me to send in a patch
which people liked. It was just a proposal. The people responsible and
a few others liked it too, and integrated it.

> I've given this some thought, particularly with respect to the
> rc.conf changes. My opinion is that, while this kind of thing is a
> good idea for from-scratch installs (the kind a person new to FreeBSD
> might be doing), making these changes to a running system is a Really
> Bad Idea. That means that if you _must_ change the defaults, add
> overrides at the same time to maintain the old default behavior.
> Then document the hell out of the new defaults. One shouldn't have
> to read ancient mail archives or pore over cvs logs to figure out
> what happened and why.

I agree. Next time i send in a patch (doesn't happen often ;)) i'll
consider this.

> IMHO, this was botched. Sorry, David, I calls 'em as I see 'em.

David?

But ehh...If people really want to change this, could someone file a PR?
:) (i can't right now, isp problems... i can only use their mailserver.
Besides, i'm not the one complaining)

From: Terry Lambert
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Tue, 23 Apr 2002 11:28:44 -0700

Jochem Kossen wrote:
> Don't tell me that in 11 years, defaults never change

When the routing code was changed, back in the mid 1990's, X.25
and ISODE were both broken, for lack of maintenance: the changes
were not made globally.

X.25 and ISODE were then removed "due to bit rot".

The entire idea of "bit rot" is really "the code did not keep
``up to date'' with my changes, which broke the code", which
is really a ridiculous position.

It really pissed me off when the AHA-1742 support dropped out
when CAM came in, but that, at least, was understandable, since
it was a trade: something deisrable for something less desirable
to the majority of users.

You really *can not* blame breaking "something that used to work
but which no longer works" on "evolution".

> I agree, but i still wonder why people didn't come up with it sooner

Mostly, because most people don't run -current, and because the
X11 distribution is not nearly as modular as it should be, if
this type of change is to be generally permitted.

> This is a very good idea IMHO, although without the patch 'startx
> -nolisten_tcp' works too...Then i'd say rip the patch out completely

That handles this particular case, but dodges the general policy
issue ...which I guess is the point: "Never put off until tomorrow
what you can put off indefinitely" ;^).

> It is useless to _me_ because i don't use it. Like i said in a previous
> mail, I didn't like the default, so I sent in the patch as a proposal
> to the ports@ mailinglist, and they all seemed to like it too. Nobody
> complained, thus the patch was integrated. Simple.

Not the most likely place for X11 people to see the issue and
become involved in a discussion: X11 is unfortunately not a proper
port in the common case, but is rather a set of distfiles: a tar
archive split into chunks, and managed by "sysinstall".

-- Terry

From: David Schultz
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Tue, 23 Apr 2002 22:23:57 -0700

Aah...we'd better put uucp back in the base system, then. Never mind
that it might have security problems that we don't know about. :P

From: Terry Lambert
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Wed, 24 Apr 2002 03:29:36 -0700

I can guarantee you that having a computer booted has security
problems that we don't know about, so the logical thing to do,
from that persepective, is to power everything off.

8^p back at ya...

-- Terry

From: David Schultz
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Wed, 24 Apr 2002 05:21:49 -0700

That would, of course, be impractical. If you want to take everything
to extremes, the other option is to ignore security entirely.

Statistically, it makes sense not to leave potentially insecure fluff
lying around unless removing the fluff would be vastly inconvenient.

The whole business of what is enabled by default is of particular
concern because many FreeBSD users are not Unix gurus. You learned
Unix before security was a major concern, but many people don't have
that advantage. The defaults should afford a reasonable degree of
security, and people should be able to turn on other features as they
begin to understand them. I am not proposing to create a system that
is virtually unusable by default, a la OpenBSD, but it is not
unreasonable to disable by default a feature that most people do not
use. People who want and understand the feature can turn it on
easily enough.

From: "Matthew N. Dodd
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Tue, 23 Apr 2002 21:24:30 -0400 (EDT)

On Tue, 23 Apr 2002, Terry Lambert wrote:
> It really pissed me off when the AHA-1742 support dropped out when CAM
> came in, but that, at least, was understandable, since it was a trade:
> something deisrable for something less desirable to the majority of
> users.

AHA-1742 works again now.

Maybe you're talking about Ultrastore 24F support?

From: Terry Lambert
Subject: Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Date: Wed, 24 Apr 2002 02:29:56 -0700

No, I was talking about 1742. I know it works again now. It
was orphaned for a long time.

-- Terry

From: "Greg 'groggy' Lehey
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Wed, 24 Apr 2002 08:44:44 +0930

On Tuesday, 23 April 2002 at 12:06:01 +0200, Jochem Kossen wrote:
>> Well, yes. But I've been using X for 11 years. Why should I have to
>> read the man page to find changes?
>
> Because things evolve? :)

Not a good reason. If they evolve, the evolution should be more
clearly documented.

>> How do I know which man page to read?
>
> You start X with startx, seems obvious to me. The disabling of tcp
> connections only applies to startx

I don't stay with startx. Next I go to xinit, then to Xwrapper, then
to X. All of these work fine. When I try to start an xterm, nothing
happens. So I read the haystack of man pages for all these programs
looking for a possible needle? That's 4314 lines of man pages
(Xwrapper doesn't have a man page, so Murphy says that it's probably
in Xwrapper). Based on prior experience, startx would be the last
place I would look. In fact, I suspected a networking problem.

>> If I did that for everything that happened, I wouldn't get any
>> work done. And you can bet your bottom dollar that somebody coming
>> from another UNIX variant and trying out FreeBSD won't do so.
>
> OK, then i suggest we mention it in the handbook, the security policy
> document, the manpage AND the release notes :)

You've heard my suggestions.

>> They'll just say that it's broken and wander off again.

I note you don't comment on this one.

>>> In the case of the X patch, i'd add it to the release notes AND the
>>> security policy document, since - i think - few people will look in
>>> the security policy document for such a problem.
>>
>> I think it shouldn't happen at all unless people agree to it.
>
> 3 people did, 0 people did not...read below

So only 3 people use X? Get real. You just haven't heard any
objections up to now. I found out about this several weeks ago, but I
didn't complain because I was expecting replies with the perspective
you're showing.

>>> I do have to say you're the first one I see who complains about
>>> this...
>>
>> Maybe the others have given up.
>
> LOL

THIS IS NO LAUGHING MATTER. It's this kind of change which is going
to stop people from using FreeBSD.

> For the simple reason I don't like useless open ports on my system. I
> don't use it, _most_ other people don't use it, so i sent in a
> patch.

Fine, I'm not telling you how to run your system. I don't want you
telling me how to run my network. I note that you still haven't given
a good technical reason for it.

> Of course, it was only discussed on the ports@ mailinglist, but it
> didn't seem like such a big deal to me or apparently the others...

That doesn't help end users. We have a user community out there.

Greg

From: Garance A Drosihn
Subject: Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
Date: Tue, 23 Apr 2002 20:01:39 -0400

At 8:44 AM +0930 4/24/02, Greg 'groggy' Lehey wrote:
> >> Well, yes. But I've been using X for 11 years. Why should I
> >> have to read the man page to find changes?

I think the first thing we need to do, before we get too worked
up, is stop taking to Jochem about it. All he did was send in
a PR with a suggestion. He's not responsible for the change
being committed into the system.

>I don't stay with startx. Next I go to xinit, then to Xwrapper,
>then to X. All of these work fine. When I try to start an xterm,
>nothing happens.

This is where we (the freebsd project) need to take a bit more
time at when we are making a change like this. I think it makes
little difference whether we document the change in UPGRADING,
or man pages, or "heads up" on the mailing lists, or errata.html
pages on the web site. There will always be some people who are
not going to see documentation like that, because it's too far
"out of the way" of what they are doing

FreeBSD: Secure By Default, Or Secure By Obscurity?

X11 Forwarding..... been there, done that...