On Sat, May 5, 2012 at 7:16 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, May 05, 2012 at 07:06:27AM -0400, Nico Kadel-Garcia wrote:
> > Well, yes. There are SSL key based authentication methods, for example.
> And
> > in theory, Kerberos can work out. Unfortunately, few small sites set up
> > Kerberos, and even sites that do don't mandate the use of the keys. Let's
> > actually look at the RHEL 6 mod_auth_kerb settings, shall we?
>
> > #<Location /private>
> > # SSLRequireSSL
> > # AuthType Kerberos
> > # AuthName "Kerberos Login"
> > # KrbMethodNegotiate On
> > # KrbMethodK5Passwd Off
> > # KrbAuthRealms EXAMPLE.COM
> > # Krb5KeyTab /etc/httpd/conf/keytab
> > # require valid-user
> > #</Location>
> > Not active by default nor configuerd for Subversion, that's OK.
> >
> > KrbMedhodK5Passwd Off:, that prevents the use of pure password negotiaton
> > and forces clients to use Kerberos tickets. Except...... if you have
> RHEL 4
> > systems, or Subversion clients from older but still active systems,
> you're
> > screwed and must use password negotiation. That means password storage on
> > the client, of your *Kerberos passwords!!!!!*
>
> The root of this problem clearly is people using severely outdated
> software. If they do this, then they must live with the feature set
> that was available at the time the now outdated software was current.
>
And they will continue to do so. I've made a fair chunk of my salary in the
last 10 years upgrading systems. And reliance on a contemporary and
underdocumented feature set for basic software security in older
environments is.... well, it's quite dangerous to unsuspecting admins.
> > Note the unlisted default setting "KrbAuthoritative On". That one, set to
> > off, allows authentication to be passwd to other modules.
>
> Yes, you can chain them. What's your point? That people would
> inadvertantly keep entering a wrong password if the server is set
> up incorrectly?
>
No, no. That in many production and development environments they'd be
unable to use the sophisticated features that might help secure HTTP or
HTTPS based access. So they'll either let it fall through to
non-properly-Kerberized access and wind up with plain text passwords, or
refuse to use the Kerberized access in the first place, and wind up right
back at the start of keeping their passwords in local clear text and having
to manage those.
I'm sorry to say that even in a properly Kerberized environment, the use of
"> # KrbMethodK5Passwd Off" is not as common as we'd like.
> > Also note: if the user is not in Kerberos, this becomes unusuable. Many
> > system accounts, such as "named" and "root", would benefit from
> centralized
> > source control access to a read-only repository. (I'm preseint about just
> > such a setup for BIND in June.) Setting up Kerberos authentication for
> > system rather than user accounts becomes.... an adventure that could
> > require a lot of thought, especially for unattended operations.
>
> That is correct. Single-sign on is not very easy in the non-interactive
> case because, well, somebody has to sign on :)
> Setting up authenticated non-interactive access is always a bit tricky.
>
> That's one of the reasons I prefer svn+ssh: it's possible to enable an
`ssh-agent`, especially with tools like "keychain", that will easily load
and preserve such a key in the local environment.
> > So it's potentially *better* to use Kerberos, but it does present
> > configuration issues. It's certainly not plug and play, and it's very
> easy
> > for people to wind up storing their passwords in the clear again, only
> this
> > time tied to their Kerberos passwords.
>
> I agree. However, your argument amounts to something like "if you create
> a subversion repository, never make backups, and then some day rm -rf
> the repository... you will lose all your data and cry". Well, yes, of
> course.
> If people don't use the system as intended, and as appropriate for their
> use cases, then what can the developers do to help them?
>
>
>
No, I'm saying "This security approach breaks down for this long list of
invividual problem cases". And it's partly why I urge the use of svn+ssh
based access, which does serve almost all the same needs but without the
same vulnerabilities. In the last six years, *none* of the multiple
Subversion server environments I've dealt with have been suitable for this
kind of Kerberized access, usually due to the need for unattended access
but often due to out of date client environments.
That sort of thing is why I've been publishing to Repoforge the backports
for RHEL 4 and RHEL 5 of current Subversions. It makes gnome-keyring
available for RHEL, and it makes subversion 1.6 and subversion 1.7
avaialble for RHEL 4, so that people will at least be *asked* before they
store plain text passwords.
Received on 2012-05-05 18:11:52 CEST