Re: BUG #14543: libpq fails with group readable ssl keys

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, "postgres(at)freigeist(dot)org" <postgres(at)freigeist(dot)org>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14543: libpq fails with group readable ssl keys
Date: 2017-03-02 23:22:59
Message-ID: CABUevEyoML_Jmr5ck96jEyau56JmnrQiA5h2CjSpDRbe0s5QvQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tuesday, February 28, 2017, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Magnus Hagander (magnus(at)hagander(dot)net <javascript:;>) wrote:
> > On Tue, Feb 28, 2017 at 12:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <javascript:;>> wrote:
> > > Bruce Momjian <bruce(at)momjian(dot)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/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Denise Wiedl 2017-03-02 23:50:33 Re: BUG #14573: lateral joins, ambuiguity
Previous Message Tom Lane 2017-03-02 19:25:22 Re: BUG #14573: lateral joins, ambuiguity