On Mon, May 23, 2022 at 4:46 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Maybe I shouldn't be putting words into Nathan's mouth, but I think > what he is after is a mode intended for use by cloud service providers, > who would like to offer locked-down database services where there's > just no way to get to the disk from inside the DB, superuser or no.
The cloud service provider use case is also what I was thinking about. > What you're talking about is perhaps interesting to a different set of > people, but it doesn't offer any guarantees because it's always possible > that $attacker manages to hack his way into access to a superuser role. I mean, you can hypothesize that any sort of restriction can be bypassed, regardless of how they're implemented. I don't think this is a valid way of discriminating among possible solutions. > The main flaw I'm aware of in that argument is that it used to be possible > for superusers to create C-language pg_proc entries pointing at random C > entry point symbols, eg open(2) or write(2), and then invoke those > functions from SQL --- maybe with only restricted possibilities for the > arguments, but you just need to find one combination that works. > When we got rid of v0 function call support, that became at least far > more difficult to exploit, but I'm not sure if it's entirely impossible. > A component of this exercise would need to be making sure that that's > bulletproof, ie you can't make a usable pg_proc entry that points at > something that wasn't meant to be a SQL-callable function. It's not just a question of whether it was meant to be SQL-callable -- it's also a question of what arguments it was expecting to be called with. At the very least, you can cause the server to core dump if you pass something that isn't a valid pointer to a function that is expecting a pointer, which is something a CSP very likely does not want a customer to be able to do. I think, however, that there's every possibility that you can create more havoc than that. You can basically call a function that's expecting a pointer with a pointer to anything you can find or guess the memory address of. Maybe that's not enough control to cause anything worse than a server crash, but I sure wouldn't bet on it. There's a lot of functions floating around, and if none of them can be tricked into doing filesystem access today, well someone might add a new one tomorrow. -- Robert Haas EDB: http://www.enterprisedb.com