BUG #14543: libpq fails with group readable ssl keys

On Tue, Feb 14, 2017 at 3:43 AM, <postgres@freigeist.org> wrote:

looks like libpq checks if a ssl key is group or world readable and aborts
if that's the case:

This is not a bug.

# pg_basebackup -R -d
'postgres://replication@db-rw?sslmode=verify-ca&sslcert=/etc/ssl/private/default.pem&sslkey=/etc/ssl/private/default-key.pem&sslrootcert=/etc/ssl/ca-trusted.pem'
-D /var/lib/postgresql/9.5/main --xlog-method=stream
pg_basebackup: could not connect to server: private key file
"/etc/ssl/private/default-key.pem" has group or world access; permissions
should be u=rw (0600) or less

This behavior comes from commit eb7afc14 of 2002.

While I agree this is reasonable to do if the key is world readable, it's
perfectly fine to make a SSL key group readable to share it with multiple
users on the same system.

I don't disagree with that. Now it is hard to justify a change for a
14-year-old behavior as many users may rely on the current way things
work as well.

Ubuntu (and probably most other distributions) even creates a group for
exactly this scenario:

Hard to assume. Fedora does not have such a patch:
http://pkgs.fedoraproject.org/cgit/rpms/postgresql.git/tree/.
Archlinux also shows none:
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/postgresql.
--
Michael

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi,

On Tue, Feb 14, 2017 at 1:01 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:

On Tue, Feb 14, 2017 at 3:43 AM, <postgres@freigeist.org> wrote:

looks like libpq checks if a ssl key is group or world readable and

aborts

if that's the case:

This is not a bug.

sorry, haven't found a way to submit 'suggestions'.

# pg_basebackup -R -d

'postgres://replication@db-rw?sslmode=verify-ca&sslcert=/

etc/ssl/private/default.pem&sslkey=/etc/ssl/private/
default-key.pem&sslrootcert=/etc/ssl/ca-trusted.pem'

-D /var/lib/postgresql/9.5/main --xlog-method=stream
pg_basebackup: could not connect to server: private key file
"/etc/ssl/private/default-key.pem" has group or world access;

permissions

should be u=rw (0600) or less

This behavior comes from commit eb7afc14 of 2002.

While I agree this is reasonable to do if the key is world readable, it's
perfectly fine to make a SSL key group readable to share it with multiple
users on the same system.

I don't disagree with that. Now it is hard to justify a change for a
14-year-old behavior as many users may rely on the current way things
work as well.

I can't imaging how someone would rely on this behavior.
I don't care that much though, I just did't want to rant about this feature
without reporting it like a good user :)

Ubuntu (and probably most other distributions) even creates a group for

exactly this scenario:

Hard to assume. Fedora does not have such a patch:
http://pkgs.fedoraproject.org/cgit/rpms/postgresql.git/tree/.
Archlinux also shows none:
https://git.archlinux.org/svntogit/packages.git/tree/
trunk?h=packages/postgresql.

I didn't mean they patch it, I mean they create a group to share ssl keys
with multiple services. Just pointed that out to proof it's established
practice to have keys group-readable.

On Mon, Feb 13, 2017 at 06:43:23PM +0000, postgres@freigeist.org wrote:

The following bug has been logged on the website:

Bug reference: 14543
Logged by: Johannes Ziemke
Email address: postgres@freigeist.org
PostgreSQL version: 9.5.6
Operating system: linux
Description:

Hi,

looks like libpq checks if a ssl key is group or world readable and aborts
if that's the case:

# pg_basebackup -R -d
'postgres://replication@db-rw?sslmode=verify-ca&sslcert=/etc/ssl/private/default.pem&sslkey=/etc/ssl/private/default-key.pem&sslrootcert=/etc/ssl/ca-trusted.pem'
-D /var/lib/postgresql/9.5/main --xlog-method=stream
pg_basebackup: could not connect to server: private key file
"/etc/ssl/private/default-key.pem" has group or world access; permissions
should be u=rw (0600) or less

# ls -al /etc/ssl/private/default-key.pem
-rw-r----- 1 root ssl-cert 1675 Feb 13 18:04
/etc/ssl/private/default-key.pem

While I agree this is reasonable to do if the key is world readable, it's
perfectly fine to make a SSL key group readable to share it with multiple
users on the same system.

Ubuntu (and probably most other distributions) even creates a group for
exactly this scenario:

# ls -l /etc/ssl/private/
total 4
-rw-r----- 1 root ssl-cert 1708 Apr 14 2016 ssl-cert-snakeoil.key

We changed Postgres 9.6 to allow open group permissions on the
_server_'s SSL key if it was owned by root:

Allow the server's <acronym>SSL</> key file to have group read
access if it is owned by <literal>root</> (Christoph Berg)

Is this something we should change on the client? I don't see why not,
but the 'root' requirement would still remain.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Bruce Momjian <bruce@momjian.us> writes:

We changed Postgres 9.6 to allow open group permissions on the
_server_'s SSL key if it was owned by root:
Allow the server's <acronym>SSL</> key file to have group read
access if it is owned by <literal>root</> (Christoph Berg)
Is this something we should change on the client? I don't see why not,
but the 'root' requirement would still remain.

I'm pretty suspicious of doing this on the client side. It doesn't seem
as useful, and it would open up a bunch of issues concerning e.g. what
cert authentication actually is authenticating.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Tue, Feb 28, 2017 at 12:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Bruce Momjian <bruce@momjian.us> writes:

We changed Postgres 9.6 to allow open group permissions on the
_server_'s SSL key if it was owned by root:
Allow the server's <acronym>SSL</> key file to have group read
access if it is owned by <literal>root</> (Christoph Berg)
Is this something we should change on the client? I don't see why not,
but the 'root' requirement would still remain.

I'm pretty suspicious of doing this on the client side. It doesn't seem
as useful, and it would open up a bunch of issues concerning e.g. what
cert authentication actually is authenticating.

It does rapidly tread into platform-specific behaviour and exactly how
groups are used, yeah.

I wonder if a better choice might be to have a way to override the
behavior. We're mostly trying to defend against an accidental
misconfiguration after all. So perhaps we should have a way to specify
something like sslkey=/foo/bar:insecure or something like that, which would
ignore the permissions check on it. In this case it's very clearly a
*voluntary* configuration that the user did, and therefor any analysis of
the security of doing it is on them, but we retain the default behavior of
clearly pointing out to a user that what they're doing might be insecure?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

* Magnus Hagander (magnus@hagander.net) wrote:

On Tue, Feb 28, 2017 at 12:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Bruce Momjian <bruce@momjian.us> writes:

We changed Postgres 9.6 to allow open group permissions on the
_server_'s SSL key if it was owned by root:
Allow the server's <acronym>SSL</> key file to have group read
access if it is owned by <literal>root</> (Christoph Berg)
Is this something we should change on the client? I don't see why not,
but the 'root' requirement would still remain.

I'm pretty suspicious of doing this on the client side. It doesn't seem
as useful, and it would open up a bunch of issues concerning e.g. what
cert authentication actually is authenticating.

It does rapidly tread into platform-specific behaviour and exactly how
groups are used, yeah.

Agreed.

I wonder if a better choice might be to have a way to override the
behavior. We're mostly trying to defend against an accidental
misconfiguration after all. So perhaps we should have a way to specify
something like sslkey=/foo/bar:insecure or something like that, which would
ignore the permissions check on it. In this case it's very clearly a
*voluntary* configuration that the user did, and therefor any analysis of
the security of doing it is on them, but we retain the default behavior of
clearly pointing out to a user that what they're doing might be insecure?

Well, I'm not keen on forcing users to say 'insecure' when, for their
particular environment, it might be just fine. "nopermcheck" or
something would be better, imv. As long as it's clearly a user
requested behavior, I don't see any issue with it.

Thanks!

Stephen

On Tuesday, February 28, 2017, Stephen Frost <sfrost@snowman.net> wrote:

* Magnus Hagander (magnus@hagander.net <javascript:;>) wrote:

On Tue, Feb 28, 2017 at 12:07 AM, Tom Lane <tgl@sss.pgh.pa.us

<javascript:;>> wrote:

Bruce Momjian <bruce@momjian.us <javascript:;>> writes:

We changed Postgres 9.6 to allow open group permissions on the
_server_'s SSL key if it was owned by root:
Allow the server's <acronym>SSL</> key file to have group read
access if it is owned by <literal>root</> (Christoph Berg)
Is this something we should change on the client? I don't see why

not,

but the 'root' requirement would still remain.

I'm pretty suspicious of doing this on the client side. It doesn't

seem

as useful, and it would open up a bunch of issues concerning e.g. what
cert authentication actually is authenticating.

It does rapidly tread into platform-specific behaviour and exactly how
groups are used, yeah.

Agreed.

I wonder if a better choice might be to have a way to override the
behavior. We're mostly trying to defend against an accidental
misconfiguration after all. So perhaps we should have a way to specify
something like sslkey=/foo/bar:insecure or something like that, which

would

ignore the permissions check on it. In this case it's very clearly a
*voluntary* configuration that the user did, and therefor any analysis of
the security of doing it is on them, but we retain the default behavior

of

clearly pointing out to a user that what they're doing might be insecure?

Well, I'm not keen on forcing users to say 'insecure' when, for their
particular environment, it might be just fine. "nopermcheck" or
something would be better, imv. As long as it's clearly a user
requested behavior, I don't see any issue with it.

Sure, I don't think the actual name is the important part, no problem with
nopermcheck or similar. As you say, the point is making it a user requested
behaviour, but providing an option for those users that really want it.

//Magnus

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/