On Mon, Jul 15, 2013 at 9:27 AM, Markus Wanner <markus@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
guyto 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
