Re: Non-superuser subscription owners

On Mon, Jan 23, 2023 at 1:27 PM Jacob Champion <jchampion@timescale.com> wrote:
> On Mon, Jan 23, 2023 at 8:35 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > I will admit that this is not an open-and-shut case, because a
> > passwordless login back to the bootstrap superuser account from the
> > local machine is a pretty common scenario and doesn't feel
> > intrinsically unreasonable to me, and I hadn't thought about that as a
> > potential attack vector.
>
> It seems to me like that's _the_ primary attack vector. I think I
> agree with you that the password requirement is an overly large
> hammer, but I don't think it's right (or safe/helpful to DBAs reading
> along) to describe it as a manufactured concern.

First, sorry about the wording. I try to get it right, but sometimes I don't.

Second, the reason why I described it as a manufactured issue is
because it's a bit like asking someone to stand under a ladder and
then complaining when they get hit in the head by a falling object.
It's not that I think it's good for people to get a free exploit to
superuser, or to get hit in the head by falling objects. It's just
that you can't have the things that together lead to some outcome
without also getting the outcome. It seems to me that we basically let
the malicious connection to the target host succeed, and then say ...
oh, never mind, we may have made this connection under false
pretenses, so we shan't use it after all. What I was attempting to
argue is that we shouldn't let things get that far. Either the victim
should be able to protect itself from the malicious connection, or the
connection attempt shouldn't be allowed in the first place, or both.
Blocking the connection attempt after the fact feels like too little,
too late.

For instance, what if the connection string itself caused SQL to be
executed on the remote side, as in the case of target_session_attrs?
Or what if we got those logon triggers that people have been wanting
for years? Or what if the remote server speaks the PostgreSQL protocol
but isn't really PostgreSQL and does ... whatever ... when you just
connect to it?

> As of SYSTEM_USER, I think this is no longer the case -- after
> connection establishment, you can ask the server who was authenticated
> and why. (It doesn't explain why you were authorized to be that
> particular user, but that seems maybe less important wen you're trying
> to disallow ambient authentication.)

I think this is too after-the-fact, as discussed above.

> If my require_auth patchset gets in, you'd be able to improve on this
> by rejecting all ambient forms of authentication at the protocol level
> (require_auth=password,md5,scram-sha-256). You could even go a step
> further and disable ambient transport authentication
> (sslcertmode=disable gssencmode=disable), which keeps a proxied
> connection from making use of a client cert or a Kerberos cache. But
> for postgres_fdw, at least, that carries a risk of disabling current
> use cases. Stephen and I had a discussion about one such case in the
> Kerberos delegation thread [1].

Yes, this is why I think that the system administrator needs to have
some control over policy, instead of just having a hard-coded rule
that applies to everyone.

I'm not completely sure that this is good enough in terms of blocking
the attack as early as I think we should. This is all happening in the
midst of a connection attempt. If the remote server says, "hey, what's
your password?" and we refuse to answer that question, well that seems
somewhat OK. But what if we're hoping to be asked for a password and
the remote server doesn't ask? Then we don't find out that things
aren't right until after we've already logged in, and that gets back
to what I talk about above.

> > To put that another way, if I'm making a connection on behalf of an
> > untrusted party, I can choose not to supply an SSL certificate, or not
> > to supply a password. But I cannot choose to not be myself.
>
> (IMO, you're driving towards a separation of the proxy identity from
> the user identity. Other protocols do that too.)

Hmm, interesting.

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