Thread: initdb recommendations
Given some of the recent hubbub and analysis of CVE entries, one part of the documentation[1] that could be further clarified is what initdb does by default, i.e. creates a cluster where users can connect with trust authentication. While this may be great for people who are hacking or running PostgreSQL in a trusted local environment, this may not make sense for many (most?) other systems. The attached patch clarifies this fact and adds a "warning" box just below the initdb examples that provides recommendations to create a more secure environment. It also removes the section that discusses this below the part that discusses securing the directory, as really this explanation should go right after the "initdb" call. (There could be an additional discussion about whether or not we want to change the default behavior for initdb, but I would suggest that a safe starting point would be to ensure we call this out) Credits to Magnus for pointing this out, and Tom + Andrew D. for review before posting to list. Jonathan [1] https://www.postgresql.org/docs/current/creating-cluster.html
Attachment
On 2019-04-05 18:11, Jonathan S. Katz wrote: > (There could be an additional discussion about whether or not we want to > change the default behavior for initdb, but I would suggest that a safe > starting point would be to ensure we call this out) I think we should just change the defaults. There is a risk of warning fatigue. initdb does warn about this, so anyone who cared could have gotten the information. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/5/19 4:58 PM, Peter Eisentraut wrote: > On 2019-04-05 18:11, Jonathan S. Katz wrote: >> (There could be an additional discussion about whether or not we want to >> change the default behavior for initdb, but I would suggest that a safe >> starting point would be to ensure we call this out) > > I think we should just change the defaults. There is a risk of warning > fatigue. initdb does warn about this, so anyone who cared could have > gotten the information. It might actually be a combination of both updating the defaults and modifying the documentation. If we introduce better defaults, we'll need an explanation of what the defaults are and why they are as such. If we don't, we certainly need to warn the user what's happening. The way it's currently written, it's very easy to miss. I also don't see how it's warning fatigue when it's both a) a feature that could put your system into a vulnerable state if you're not careful and b) the only warning on that page. Jonathan
Attachment
On Fri, Apr 5, 2019 at 10:58 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 2019-04-05 18:11, Jonathan S. Katz wrote:
> (There could be an additional discussion about whether or not we want to
> change the default behavior for initdb, but I would suggest that a safe
> starting point would be to ensure we call this out)
I think we should just change the defaults. There is a risk of warning
fatigue. initdb does warn about this, so anyone who cared could have
gotten the information.
I've been suggesting that for years, so definite strong +1 for doing that.
If it's something that annoys backend developers who initdb very often, I suggest we add an environment variable to override it. But I'm not sure that's really necessary -- creating a shell alias or similar is easy to do, and most have probably already done so for other reasons.
That said, I think it would make sense to *also* have a warning. And in particular, we should strongly consider backpatching a warning.
On Sat, Apr 06, 2019 at 11:35:44AM +0200, Magnus Hagander wrote: > On Fri, Apr 5, 2019 at 10:58 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2019-04-05 18:11, Jonathan S. Katz wrote: > > > (There could be an additional discussion about whether or not we want to > > > change the default behavior for initdb, but I would suggest that a safe > > > starting point would be to ensure we call this out) > > > > I think we should just change the defaults. There is a risk of warning > > fatigue. initdb does warn about this, so anyone who cared could have > > gotten the information. > > > > I've been suggesting that for years, so definite strong +1 for doing that. +1 > If it's something that annoys backend developers who initdb very often, I > suggest we add an environment variable to override it. But I'm not sure > that's really necessary -- creating a shell alias or similar is easy to do, > and most have probably already done so for other reasons. I, for one, do most initdb runs via a script and wouldn't use such an environment variable.
On 2019-04-05 18:11, Jonathan S. Katz wrote: > + <para> > + We recommend using the <option>-W</option>, <option>--pwprompt</option>, > + or <option>--pwfile</option> flags to assign a password to the database > + superuser, and to override the <filename>pg_hba.conf</filename> default > + generation using <option>-auth-local peer</option> for local connections, > + and <option>-auth-host scram-sha-256</option> for remote connections. See > + <xref linkend="client-authentication"/> for more information on client > + authentication methods. > + </para> As discussed on hackers, we are not ready to support scram-sha-256 out of the box. So this advice, or any similar advice elsewhere, would need to recommend "md5" as the setting --- which would probably be embarrassing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/8/19 8:25 AM, Peter Eisentraut wrote: > On 2019-04-05 18:11, Jonathan S. Katz wrote: >> + <para> >> + We recommend using the <option>-W</option>, <option>--pwprompt</option>, >> + or <option>--pwfile</option> flags to assign a password to the database >> + superuser, and to override the <filename>pg_hba.conf</filename> default >> + generation using <option>-auth-local peer</option> for local connections, >> + and <option>-auth-host scram-sha-256</option> for remote connections. See >> + <xref linkend="client-authentication"/> for more information on client >> + authentication methods. >> + </para> > > As discussed on hackers, we are not ready to support scram-sha-256 out > of the box. So this advice, or any similar advice elsewhere, would need > to recommend "md5" as the setting --- which would probably be embarrassing. Well, it's less embarrassing than trust, and we currently state: "Also, specify -A md5 or -A password so that the default trust authentication mode is not used"[1] We could also modify it to say : "and <option>-auth-host scram-sha-256</option> for remote connections if your client supports it, otherwise <option>-auth-host md5</option>" Jonathan [1] https://www.postgresql.org/docs/current/creating-cluster.html
Attachment
On Mon, Apr 8, 2019 at 2:41 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 4/8/19 8:25 AM, Peter Eisentraut wrote:
> On 2019-04-05 18:11, Jonathan S. Katz wrote:
>> + <para>
>> + We recommend using the <option>-W</option>, <option>--pwprompt</option>,
>> + or <option>--pwfile</option> flags to assign a password to the database
>> + superuser, and to override the <filename>pg_hba.conf</filename> default
>> + generation using <option>-auth-local peer</option> for local connections,
>> + and <option>-auth-host scram-sha-256</option> for remote connections. See
>> + <xref linkend="client-authentication"/> for more information on client
>> + authentication methods.
>> + </para>
>
> As discussed on hackers, we are not ready to support scram-sha-256 out
> of the box. So this advice, or any similar advice elsewhere, would need
> to recommend "md5" as the setting --- which would probably be embarrassing.
Well, it's less embarrassing than trust, and we currently state:
Yes. Much less.
"Also, specify -A md5 or -A password so that the default trust
authentication mode is not used"[1]
We could also modify it to say :
"and <option>-auth-host scram-sha-256</option> for remote connections if
your client supports it, otherwise <option>-auth-host md5</option>"
That would be the best from a correctness, but if of course also makes things sound more complicated. I'm not sure where the right balance is there.
On 4/8/19 8:44 AM, Magnus Hagander wrote: > On Mon, Apr 8, 2019 at 2:41 PM Jonathan S. Katz <jkatz@postgresql.org > <mailto:jkatz@postgresql.org>> wrote: > > On 4/8/19 8:25 AM, Peter Eisentraut wrote: > > On 2019-04-05 18:11, Jonathan S. Katz wrote: > >> + <para> > >> + We recommend using the <option>-W</option>, > <option>--pwprompt</option>, > >> + or <option>--pwfile</option> flags to assign a password to > the database > >> + superuser, and to override the > <filename>pg_hba.conf</filename> default > >> + generation using <option>-auth-local peer</option> for > local connections, > >> + and <option>-auth-host scram-sha-256</option> for remote > connections. See > >> + <xref linkend="client-authentication"/> for more > information on client > >> + authentication methods. > >> + </para> > > > > As discussed on hackers, we are not ready to support scram-sha-256 out > > of the box. So this advice, or any similar advice elsewhere, > would need > > to recommend "md5" as the setting --- which would probably be > embarrassing. > > Well, it's less embarrassing than trust, and we currently state: > > > Yes. Much less. > > > "Also, specify -A md5 or -A password so that the default trust > authentication mode is not used"[1] > > We could also modify it to say : > > "and <option>-auth-host scram-sha-256</option> for remote connections if > your client supports it, otherwise <option>-auth-host md5</option>" > > > That would be the best from a correctness, but if of course also makes > things sound more complicated. I'm not sure where the right balance is > there. We could link here[1] from the docs on the line for "client supports it" Jonathan [1] https://wiki.postgresql.org/wiki/List_of_drivers