Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Subject: Re: running logical replication as the subscription owner
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: <CA+TgmoYE-_FssffxqdQNgGCQSueiEop8MEmOyHnTK5NST3vENQ@mail.gmail.com>
Date: Fri, 24 Mar 2023 13:11:10 -0700
Cc: Jeff Davis <pgsql@j-davis.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 Andres Freund <andres@anarazel.de>,
 Noah Misch <noah@leadboat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D54D77A-20F2-42EC-8167-586C65E7074A@enterprisedb.com>
References: <CA+TgmoaSCkg9ww9oppPqqs+9RVqCexYCE6Aq=UsYPfnOoDeFkw@mail.gmail.com>
 <68d5974b80e54672b59ff13e59d046c1e982fcd8.camel@j-davis.com>
 <CA+TgmoaE35kKS3-zSvGiZszXP9Tb9rNfYzT=+fO8Ehk5EDKrag@mail.gmail.com>
 <AF8607E7-A303-4ACD-A749-8ACF122751EA@enterprisedb.com>
 <CA+TgmoYE-_FssffxqdQNgGCQSueiEop8MEmOyHnTK5NST3vENQ@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/3D54D77A-20F2-42EC-8167-586C65E7074A%40enterprisedb.com>
Precedence: bulk


> On Mar 24, 2023, at 11:35 AM, Robert Haas <robertmhaas@gmail.com> =
wrote:
>=20
> I don't know how bad that sounds to you, and if it does sound bad, I
> don't immediately see how to mitigate it. As I said to Jeff, if you
> can replicate into a table that has a casually-written SECURITY
> INVOKER trigger on it, you can probably hack into the table owner's
> account.

I assume you mean this bit:

> > Imagine for example that the table
> > owner has a trigger which doesn't sanitize search_path. The
> > subscription owner can potentially leverage that to get the table
> > owner's privileges.


I don't find that terribly convincing.  First, there's no reason a =
subscription owner should be an ordinary user able to volitionally do =
anything.  The subscription owner should just be a role that the =
subscription runs under, as a means of superuser dropping privileges =
before applying changes.  So the only real problem would be that the =
changes coming from the publisher might, upon application, hack the =
table owner.  But if that's the case, the table owner's vulnerability on =
the subscription-database side is equal to their vulnerability on the =
publication-database side (assuming equal schemas on both).  Flagging =
this vulnerability as being logical replication related seems a category =
error.  Instead, it's a schema vulnerability.

> So I think that if we allow user A to replicate into user B's
> table with fewer privileges than A-can-set-role-to-B, we're building a
> privilege-escalation attack into the system. But if we do require
> A-can-set-role-to-B, then things change as described above.

I don't understand the direction this patch is going.  I'm emphatically =
not objecting to it, merely expressing my confusion about it.

I had imagined the solution to the replication security problem was to =
stop running the replication as superuser, and instead as a trivial =
user.  Imagine that superuser creates roles "deadhead_bob" and =
"deadhead_alice" which cannot log in, are not members of any groups nor =
have any other roles as members of themselves, and have no privileges =
beyond begin able to replicate into bob's and alice's tables, =
respectively.  The superuser sets up the subscriptions disabled, =
transfers ownership to deadhead_bob and deadhead_alice, and only then =
enables the subscriptions.

Since deadhead_bob and deadhead_alice cannot log in, and nobody can set =
role to them, I don't see what the vulnerability is.  Sure, maybe alice =
can attack deadhead_alice, or bob can attack deadhead_bob, but that's =
more of a privilege deescalation than a privilege escalation, so where's =
the risk?  That's not a rhetorical question.  Is there a risk here?  Or =
are we just concerned that most users will set up replication with =
superuser or some other high-privilege user, and we're trying to protect =
them from the consequences of that choice?

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company