Thread: ldapbindpasswdfile

Hello hackers,

Some users don't like the fact that ldapbindpasswd can leak into logs
(and now system views?).  Also, some users don't like the fact that it
is in cleartext rather than some encryption scheme (though I don't
know what, since we'd presumably also need the key).  I propose a new
option $SUBJECT so that users can at least add a level of indirection
and put the password in a file.  A motivated user could point it at an
encrypted loopback device so that they need a passphrase at mount
time, or a named pipe that performs arbitrary magic.  Some of these
topics were discussed last time someone had this idea[1].

Using a separate file for the bind password is fairly common in other
software: see the ldapsearch's -y switch, and I think it probably
makes sense at the very least as a convenience, without getting into
hand-wringing discussions about whether any security is truly added.

Draft patch attached.

Hi Stephen!

I also know that a motivated user could also use GSSAPI instead of
LDAP.  Do you think we should update the manual to say so, perhaps in
a "tip" box on the LDAP auth page?

[1] https://www.postgresql.org/message-id/flat/20140617175511.2589.45249%40wrigleys.postgresql.org

-- 
Thomas Munro
https://enterprisedb.com

On Tue, May 14, 2019 at 1:49 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> ... or a named pipe that performs arbitrary magic.

(Erm, that bit might not make much sense...)

-- 
Thomas Munro
https://enterprisedb.com

> On 14 May 2019, at 03:49, Thomas Munro <thomas.munro@gmail.com> wrote:

> I propose a new option $SUBJECT so that users can at least add a level of
> indirection and put the password in a file.


+1, seems like a reasonable option to give.

> Draft patch attached.

I might be a bit thick, but this is somewhat hard to parse IMO:

+        File containing the password for user to bind to the directory with to
+        perform the search when doing search+bind authentication

To add a little bit more security around this, does it make sense to check (on
unix filesystems) that the file isn’t world readable/editable?

+   fd = OpenTransientFile(path, O_RDONLY);
+   if (fd < 0)
+       return -1;

cheers ./daniel

On Tue, May 14, 2019 at 1:24 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> > On 14 May 2019, at 03:49, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> > I propose a new option $SUBJECT so that users can at least add a level of
> > indirection and put the password in a file.
>
> +1, seems like a reasonable option to give.

Thanks for the review!

> > Draft patch attached.
>
> I might be a bit thick, but this is somewhat hard to parse IMO:
>
> +        File containing the password for user to bind to the directory with to
> +        perform the search when doing search+bind authentication
>
> To add a little bit more security around this, does it make sense to check (on
> unix filesystems) that the file isn’t world readable/editable?
>
> +   fd = OpenTransientFile(path, O_RDONLY);
> +   if (fd < 0)
> +       return -1;

Good point.

However, I realised that this patch is nearly but not quite redundant.
You can already write @somefile given a file somefile that contains
ldapbindpasswd=secret.  It'd be a bit nicer if you could also write
ldapbindpasswd=@somefile to include just the value, and not have to
include the option name in the file.  Then you could use the same
password file that you use for the ldapsearch command line tool, and
in general that seems nicer.  That syntax might have backwards
compatibility problems though.  You could probably resolve any
problems by requiring quote marks around @ signs that are not acting
as include directives, or something like that.  If we do that, I'd
also like to be able to write ldapbindpasswd=$SOME_ENV_VAR.

Anyway, I hereby withdraw the earlier patch; it seems silly to do
per-option ad hoc read-from-file variants.  Perhaps we can do
something much better and more general, or perhaps what we have is
enough already.

--
Thomas Munro
https://enterprisedb.com

Greetings,

* Thomas Munro (thomas.munro@gmail.com) wrote:
> I also know that a motivated user could also use GSSAPI instead of
> LDAP.  Do you think we should update the manual to say so, perhaps in
> a "tip" box on the LDAP auth page?

Hrm, not sure how I missed this before, but, yes, I'm all for adding a
'tip' box on the LDAP auth page which recommends use of GSSAPI when
available (such as when operating in an Active Directory
environment...).  Note that, technically, you can run LDAP without using
Active Directory and without running any kind of KDC, so we can't just
blanket say "use GSSAPI" because there exists use-cases where that isn't
an option.

Not that I've ever actually *encountered* such an environment, but
people have assured me that they do, in fact, exist, and that there are
users of PG LDAP auth with such a setup who would be upset to see
support for it removed.

Anyhow, yes, a 'tip' would be great to add.

Thanks,

Stephen