On Mon, Jul 15, 2013 at 9:27 AM, Markus Wanner <mar...@bluegap.ch> wrote: > To clarify: In the above agreement, I had the Postgres level ordinary > users in mind, who certainly shouldn't ever be able to upload and run > arbitrary native code. > > I'm not quite as enthusiastic if you meant the system level user that > happens to have superuser rights on Postgres. As Andres pointed out, > there are some more holes to plug, if you want to lock down a superuser > account. [1] > > I'm not quite clear what kind of "user" you meant in your statement above.
I'm talking about people who are accessing the database via SQL (with or without superuser privileges) rather than people who are accessing the database via the file system (regardless of which OS user they authenticate as). As things stand today, the only way to get machine code to run inside the Postgres binary is to have local filesystem access. Andres points out that you can install adminpack to obtain local filesystem access, and that is true. But the system administrator can also refuse to allow adminpack, and/or use selinux or other mechanisms to prevent the postgres binary from writing a file with execute permissions. If, however, we change things so that Postgres can grab bits out of a system catalog and map them, with execute permissions, into its own memory space, and then jump to that address, we've effectively installed a backdoor around those types of OS-level security measures. And we've made it quite a lot easier for a bad guy to install a rootkit within postgres. Things aren't quite so bad if we write the bits to a file first and then dynamically load the file. That way at least noexec or similar can provide protection. But it still seems like a pretty dangerous direction. I'm inclined to think any such thing would have to be an extension that administrators could enable at their own risk, rather than something that we enabled by default. Insufficient privilege separation is one of the things that has made security on Microsoft Windows such a huge problem over the last several decades; I don't want us to emulate that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
