Обсуждение: [BUGS] BUG #14543: libpq fails with group readable ssl keys
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 -- 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 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 (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
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.
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/