Re: Non-superuser subscription owners - Mailing list pgsql-hackers

Hi,

On 2023-01-20 08:25:46 -0500, Robert Haas wrote:
> Worse still, I have always felt that the security vulnerability that
> led to these controls being installed is pretty much fabricated: it's
> an imaginary problem. Today I went back and found the original CVE at
> https://nvd.nist.gov/vuln/detail/CVE-2007-3278 and it seems that at
> least one other person agrees. The Red Hat vendor statement on that
> page says: "Red Hat does not consider this do be a security issue.
> dblink is disabled in default configuration of PostgreSQL packages as
> shipped with Red Hat Enterprise Linux versions 2.1, 3, 4 and 5, and it
> is a configuration decision whether to grant local users arbitrary
> access." I think whoever wrote that has an excellent point. I'm unable
> to discern any legitimate security purpose for this restriction. What
> I think it mostly does is (a) inconvenience users or (b) force them to
> rely on a less-secure authentication method than they would otherwise
> have chosen.

FWIW, I've certainly seen situations where having the checks prevented easy
paths to privilege escalations. That's not to say that I like the checks, but
I also don't think we can get away without them (or a better replacement, of
course).

There are good reasons to have 'peer' authentication set up for the user
running postgres, so admin scripts can connect without issues. Which
unfortunately then also means that postgres_fdw etc can connect to the current
database as superuser, without that check. Which imo clearly is an issue.

Why do you think this is a fabricated issue?


The solution we have is quite bad, of course. Just because the user isn't a
superuser "immediately" doesn't mean it doesn't have the rights to become
one somehow.


> > > The basic idea that by looking at which connection string properties are set
> > > we can tell what kinds of things the connection string is going to do seems
> > > sound to me.
> >
> > I don't think you *can* check it purely based on existing connection string
> > properties, unfortunately. Think of e.g. a pg_hba.conf line of "local all user
> > peer" (quite reasonable config) or "host all all 127.0.0.1/32 trust" (less so).
> >
> > Hence the hack with dblink_security_check().
> >
> > I think there might be a discussion somewhere about adding an option to force
> > libpq to not use certain auth methods, e.g. plaintext password/md5. It's
> > possible this could be integrated.
> 
> I still think you're talking about a different problem here. I'm
> talking about the problem of knowing whether local files are going to
> be accessed by the connection string.

Why is this only about local files, rather than e.g. also using the local
user?

Greetings,

Andres Freund