public inbox for [email protected]
help / color / mirror / Atom feedFrom: Mark Dilger <[email protected]>
To: Robert Haas <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Noah Misch <[email protected]>
Subject: Re: running logical replication as the subscription owner
Date: Fri, 24 Mar 2023 13:11:10 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoYE-_FssffxqdQNgGCQSueiEop8MEmOyHnTK5NST3vENQ@mail.gmail.com>
References: <CA+TgmoaSCkg9ww9oppPqqs+9RVqCexYCE6Aq=UsYPfnOoDeFkw@mail.gmail.com>
<[email protected]>
<CA+TgmoaE35kKS3-zSvGiZszXP9Tb9rNfYzT=+fO8Ehk5EDKrag@mail.gmail.com>
<[email protected]>
<CA+TgmoYE-_FssffxqdQNgGCQSueiEop8MEmOyHnTK5NST3vENQ@mail.gmail.com>
> On Mar 24, 2023, at 11:35 AM, Robert Haas <[email protected]> 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
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: running logical replication as the subscription owner
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox