> On Mar 24, 2023, at 11:35 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
> 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?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
