MIME-Version: 1.0
References: <66f55a6b9ff7bdd6bfd0d05e8fd8351690e69e23.camel@j-davis.com>
 <CAAWbhmiL=kWT=Oc=SA-U9-NnVSPGmPmzD4aNQEtahxXpCDrH0A@mail.gmail.com>
 <CA+Tgmoa+CLg8JW_Rj12pmj2Y+0D=r339yryHQmdGAdd56PcdYw@mail.gmail.com>
 <CA+TgmoamMHL2BTiMOVJtjAfHOy984=42Dvq8B0k+=p4rhYKCKw@mail.gmail.com>
 <6ef7d0b0-3255-68c3-73b2-e6023b241222@timescale.com> <CA+Tgmobc_KUw1CnP4--Zss3Y_FhAnb+FyXHwn9Ej9jTBHM238A@mail.gmail.com>
 <CAAWbhmgnLt57UH7j6VECLbxr5G9gAuJX__iXos7kF8fAnY_NqA@mail.gmail.com>
 <CA+TgmoaNCKdVp4ur0QGjVdeETYNC-hpDArQuyDNTJM3-rJdWQg@mail.gmail.com>
 <0768cedb-695a-8841-5f8b-da2aa64c8f3a@timescale.com> <CA+TgmobpVTMan6zR8rgBNcamc1Hwn0uH-gjuOR9DLB1H-h+saQ@mail.gmail.com>
 <CAAWbhmhV6JqcCpy+6qTs75OCVpkm+FviMKuZhewDQdSdbg+1bg@mail.gmail.com>
 <CA+TgmobJ1sGukOjSZT3vh=7MxW33UKdm6HWVmDbZRGwtn_rKCw@mail.gmail.com>
 <CAAWbhmi-PvUif0c5V=p99Bc4TA20nTim7K4o0x6HXnRVGKpo9A@mail.gmail.com>
 <CA+TgmoZvSSRYAdfppHiYC25CB1f2s5fNvSJ=0kMEGdicRdk2dg@mail.gmail.com>
 <cb43e26f-d897-447c-a795-b3954815f371@timescale.com> <CA+Tgmobit_-XTGJxZ0kzxJ7KSasQShxJz-oBGJCDbzPjL6s2-g@mail.gmail.com>
 <CAAWbhmg25XaA=s04y7_LK8Q7-GSBw09fH2A5iiFESUbVaFXWqg@mail.gmail.com>
 <CA+TgmoYBF75-MQ02K=4-JA02YvfLA1bsWdbjQP=evfjJGigsbA@mail.gmail.com>
 <CAAWbhmhPFvV=TyGw0GfdLNUR6GMU0Ntcg6fEuhTNcha6f2oGig@mail.gmail.com>
 <CA+TgmoYk5FCnzQFEsYJAUq4PgAkRcTn9Gy1gr28_rkP-FD=kBQ@mail.gmail.com> <CAAWbhmhRn1QnV=HiM_5X0s+1Az8DTdgXROwguMj2ZMCvNi1TcA@mail.gmail.com>
In-Reply-To: <CAAWbhmhRn1QnV=HiM_5X0s+1Az8DTdgXROwguMj2ZMCvNi1TcA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 20 Mar 2023 12:32:00 -0400
Message-ID: <CA+TgmoZasHd3VdKrhbiJDduUWewVzc_bcM2ZAYg9ePgrbQyZVQ@mail.gmail.com>
Subject: Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security
To: Jacob Champion <jchampion@timescale.com>
Cc: Andres Freund <andres@anarazel.de>, Mark Dilger <mark.dilger@enterprisedb.com>, 
	Jeff Davis <pgsql@j-davis.com>, Amit Kapila <amit.kapila16@gmail.com>, 
	Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoZasHd3VdKrhbiJDduUWewVzc_bcM2ZAYg9ePgrbQyZVQ%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 10, 2023 at 7:00=E2=80=AFPM Jacob Champion <jchampion@timescale=
.com> wrote:
> On Thu, Mar 9, 2023 at 6:17=E2=80=AFAM Robert Haas <robertmhaas@gmail.com=
> wrote:
> > That seems like a circular argument. If you call the problem the
> > confused deputy problem then the issue must indeed be that the deputy
> > is confused, and needs to talk to someone else to get un-confused. But
> > why is the deputy necessarily confused in the first place? Our deputy
> > is confused because our code to decide whether to proxy a connection
> > or not is super-dumb,
>
> No, I think our proxy is confused because it doesn't know what power
> it has, and it can't tell the server what power it wants to use. That
> problem is independent of the decision to proxy. You're suggesting
> strengthening the code that makes that decision -- adding an oracle
> (in the form of a DBA) that knows about the confusion and actively
> mitigates it. That's guaranteed to work if the oracle is perfect,
> because "perfect" is somewhat tautologically defined as "whatever
> ensures secure operation". But the oracle doesn't reduce the
> confusion, and DBAs aren't perfect.

I think this is the root of our disagreement. My understanding of the
previous discussion is that people think that the major problem here
is the wraparound-to-superuser attack. That is, in general, we expect
that when we connect to a database over the network, we expect it to
do some kind of active authentication, like asking us for a password,
or asking us for an SSL certificate that isn't just lying around for
anyone to use. However, in the specific case of a local connection, we
have a reliable way of knowing who the remote user is without any kind
of active authentication, namely 'peer' authentication or perhaps even
'trust' if we trust all the local users, and so we don't judge it
unreasonable to allow local connections without any form of active
authentication. There can be some scenarios where even over a network
we can know the identity of the person connecting with complete
certainty, e.g. if endpoints are locked down such that the source IP
address is a reliable indicator of who is initiating the connection,
but in general when there's a network involved you don't know who the
person making the connection is and need to do something extra to
figure it out.

If you accept this characterization of the problem, then I don't think
the oracle is that hard to design. We simply set it up not to allow
wraparound connections, or maybe even more narrowly to not allow
wraparound connections to superuser. If the DBA has some weird network
topology where that's not the correct rule, either because they want
to allow wraparound connections or they want to disallow other things,
then yeah they have to tell us what to allow, but I don't really see
why that's an unreasonable expectation. I'd expect the correct
configuration of the proxy facility to fall naturally out of what's
allowed in pg_hba.conf. If machine A is configured to accept
connections from machines B and C based on environmental factors, then
machines B and C should be configured not to proxy connections to A.
If machines B and C aren't under our control such that we can
configure them that way, then the configuration is fundamentally
insecure in a way that we can't really fix.

I think that what you're proposing is that B and C can just be allowed
to proxy to A and A can say "hey, by the way, I'm just gonna let you
in without asking for anything else" and B and C can, when proxying,
react to that by disconnecting before the connection actually goes
through. That's simpler, in a sense. It doesn't require us to set up
the proxy configuration on B and C in a way that matches what
pg_hba.conf allows on A. Instead, B and C can automatically deduce
what connections they should refuse to proxy. I guess that's nice, but
it feels pretty magical to me. It encourages the DBA not to think
about what B and C should actually be allowed to proxy, and instead
just trust that the automatics are going to prevent any security
disasters. I'm not sure that they always will, and I fear cultivating
too much reliance on them. I think that if you're setting up a network
topology where the correct rule is something more complex than "don't
allow wraparound connections to superuser," maybe you ought to be
forced to spell that rule out instead of letting the system deduce one
that you hope will be right.

--=20
Robert Haas
EDB: http://www.enterprisedb.com