On Fri, Mar 10, 2023 at 7:00 PM Jacob Champion <jchamp...@timescale.com> wrote: > On Thu, Mar 9, 2023 at 6:17 AM Robert Haas <robertmh...@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. -- Robert Haas EDB: http://www.enterprisedb.com
