On Tue, 23 Apr 2002, Greg 'groggy' Lehey wrote:
> On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote:
> >> That fix relies on the extensive PAM updates in -CURRENT however; in
> >> -STABLE it can probably be similarly replicated via appropriate tweaking
> >> of sshd (?).
> > 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. :(
> 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.
A more conservative default configuration results in a material
improvement in system security. This is especially the case for older
system features that aren't being used by many current users. For
example, the choice to move to telnetd turned off by default is
particularly justified these days because we have a better option: SSH.
There have even been serious discussions about not installing telnetd by
default, although personally I see no problem installing it. The risks
with telnetd on by default have been felt: witness the telnetd
vulnerability that turned up last year. Highly complex server code
enabled by default isn't useful, it's a security risk. Given these basic
facts, you can then argue about what features fall into this category, and
we can go on regarding that for a while. A reasonable set of criteria
- There have been past vulnerabilities that were exploitable by having the
feature enabled by default.
- The complexity and exposure of the feature lends it to future
- Turning the feature on is difficult or impossible without high levels of
- The feature does/does not have more secure alternatives accepted by the
"Security by obscurity" does not refer to the act of selecting a
conservative security policy, because "Security by obscurity" already
refers to something else: relying on the level of knowledge of the
attacker regarding your configuration. Since we can demonstrate disabling
telnetd by default improves security, it is by definition not security by
obscurity. And frankly, that applies to X11 also.
"Security by obscurity" might be argued to include the S/Key behavior in
the older sshd, where S/key prompts are displayed for a user even though
they could not be used to log in. Frankly, I think such an argument would
be reasonable. In fact, so reasonable that in -CURRENT, we don't have
this behavior by default: we don't offer the S/Key authentication method
to a user unless they can authenticate using S/Key. The old behavior can
be turned back on via a pam.d flag for the skey module.
BTW, there's a lot to be said for not throwing out the baby with the
bathwater: disabling challenge response or S/Key by default isn't the
right answer either. The right fix is to remove the counter-intuitive
behavior regarding S/Key.
> 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.
We've spent some time working on this, and will continue to do so. But we
also need to avoid over-burdening the install with "Do you want to turn on
(this obsolete feature that some FreeBSD hacker loves and no one uses),
even though it increases security risk?". Rather, we need a decent
> 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.
Part of your confusion is probably because X11 isn't part of the base
system, so events concerning the X11 port don't tend to get discussed much
on the general-purpose mailing lists. These kinds of things do get
discussed on the release engineering lists, questions, etc. It may be we
need a "ports release notes", but that's an effort that's going to have to
come out of the ports space.
BTW, another reason few people noticed is that at this point, the accepted
best practice for X11 forwarding is to use SSH, which can forward
TCP-based X11 to the unix domain socket X11 communication primitive. The
result is that X11/TCP turned off on your workstation doesn't limit access
when you log into remote servers using SSH, as long as you have X11
forwarding enabled for the server you're logging into.
BTW, my notion of ease of use for services would be something like the
following: a menu with a tree of services organized by category, with easy
click options to turn them on and off. I played with looking at something
like that for inetd.conf, but the best option was to toss the user into
the editor with a bit of warning. So that's what I stuck in sysinstall.
Fundamentally, we don't offer a decent management paradigm for the
majority of the base system or the applications. That's the problem that
needs addressing, and I would argue your effort would be better placed
fixing that problem. The choices regarding disabling features and
services by default have generally been made carefully, with lots of
discussion, and based on a fairly rational process balancing functionality
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
email@example.com NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message