[Nsspampgsql-devel] Bug#550332: Bug#550332: libnss-pgsql2: Need possibility to authenticate pgsql user via Kerberos

[Stephen Gran]

This one time, at band camp, Денис said:
> On Sat, 10 Oct 2009 13:13:42 +0100 Stephen Gran <sgran at debian.org>
> wrote:
> 
> > so each user will need a keytab to access the database before name
> > resolution will work for them.
> 
> I think it's okay, because it will be principal for a special DB user
> who can only do SELECT and not able to change base. And information
> from the passwd is not secret for any user.

I don't believe that's true, see below.

> >  This will be a severe boot strap problem - you'll need to be logged
> >  in to run kinit to verify who you are before you can log in.
> 
> What about use a separate keytab-file specially for nss-pgsql,
> readable for all users, with 444 permissions?

That's not my understanding of how kerberos works.  You have a keytab
per user or service, and receive principals for access to services.
It's not really clear to me how you would have a shared keytab for all
users.  It's also not clear to me that you can have a user access the
database as another user with kerberos - one of the points of kerberos,
after all, is to prove your identity.

> > This software is bascially dead upstream as far as I can tell,
> 
> :( Very strange, I thought that this is one of the most used server
> software

Postgres yes, libnss-pgsql no.

> > and I seem to be the only one looking after it in Debian at the
> > moment.  I think that kerberos isn't suited for this, unless you can
> > convince me otherwise, so I'm not likely to spend any time on this
> > problem.  If you can show me I'm misunderstanding how the process
> > can work, I'll be happy to look at how hard it would be to add
> > support.
> 
> Kerberos is suitable, in principle, to authenticate all users, servers
> or services. He has a great advantage: it also automatically ensures
> that the server is not a fake.  This warranty gives the same
> SSL-certificate, but using them is not convenient in comparison with
> Kerberos (they must be specifically generated and signed).

I don't think I'm managing to communicate the problem here.  Let me try
to restate the problem I see.

On login, the login program will attempt to resolve your name to a
numeric uid (so that the running process can suid to your uid).  This
resolution will invoke the code in libnss-pgsql _before the user has
logged in_.  If access to the database is kerberos based, it cannot
access the database at this point, since it won't have a principal in
the user's keytab.  Am I missing something?

> But for the NSS is very important to protect against fake server,
> otherwise it is a serious security hole.

Relying on network services always brings a trade off between convenience
and security.  This particular case is no worse than many others, so
lets not raise the security bugbear without due cause.  Kerberos does
help for some situations, but I don't see how it can work here.

At any rate, if you can describe how you would overcome the hurdles I've
described, let's proceed.  If not, I think this is kind of a dead end.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran at debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/nsspampgsql-devel/attachments/20091010/709e94a1/attachment.pgp>