Re: Exposure related to GUC value of ssl_passphrase_command

At Thu, 13 Feb 2020 02:37:29 +0900, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote in
> On Fri, Nov 8, 2019 at 4:24 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> >
> > Hello.
> >
> > On Tue, Nov 5, 2019 at 5:15 PM Moon, Insung <tsukiwamoon(dot)pgsql(at)gmail(dot)com> wrote:
> > > Deal Hackers.
> > >
> > > The value of ssl_passphrase_command is set so that an external command
> > > is called when the passphrase for decrypting an SSL file such as a
> > > private key is obtained.
> > > Therefore, easily set to work with echo "passphrase" or call to
> > > another get of passphrase application.
> > >
> > > I think that this GUC value doesn't contain very sensitive data,
> > > but just in case, it's dangerous to be visible to all users.
> > > I think do not possible these cases, but if a used echo external
> > > commands or another external command, know what application used to
> > > get the password, maybe we can't be convinced that there's the safety
> > > of using abuse by backtracking on applications.
> > > So I think to the need only superusers or users with the default role
> > > of pg_read_all_settings should see these values.
> > >
> > > Patch is very simple.
> > > How do you think about my thoughts like this?
> >
> > I'm hardly an expert on this topic, but reading this blog post about
> > ssl_passphrase_command:
> >
> > https://www.2ndquadrant.com/en/blog/postgresql-passphrase-protected-ssl-keys-systemd/
> >
> > which mentions that some users might go with the very naive
> > configuration such as:
> >
> > ssl_passphrase_command = 'echo "secret"'
> >
> > maybe it makes sense to protect its value from everyone but superusers.
> >
> > So +1.
>
> Seems this proposal is reasonable.

I think it is reasonable.

By the way, I'm not sure the criteria of setting a GUC variable as
GUC_SUPERUSER_ONLY, but for example, ssl_max/min_protocol_version,
dynamic_library_path, log_directory, krb_server_keyfile,
data_directory and config_file are GUC_SUPERUSER_ONLY. So, it seems to
me very strange that ssl_*_file are not. Don't we need to mark them
maybe and some of the other ssl_* as the same?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center