On 07/16/2013 01:27 AM, Robert Haas wrote: > 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.
I think execute permissions (on the FS) are irrelevant. It's about loading a shared library. The noexec mount option can prevent that, though. But okay, you're saying we *have* and *want* a guarantee that even a superuser cannot execute arbitrary native code via libpq (at least in default installs w/o extensions). Andres made two contrib-free suggestions: with COPY TO BINARY, you get a header prepended, which I think is sufficient to prevent a dlopen() or LoadLibrary(). Text and CSV formats of COPY escape their output, so it's hard to write \000 or other control bytes. ESCAPE and DELIMITER also have pretty restrictive requirements. So COPY doesn't seem quite "good" enough to write a valid DSO. His second suggestion was tuplesort tapes. tuplesort.c says: "We require the first "unsigned int" of a stored tuple to be the total size on-tape of the tuple...". That's kind of a header as well. Writing a proper DSO certainly does not sound trivial, either. >From a security perspective, I wouldn't want to rely on that guarantee. Postgres writes too many files to be sure none of those can be abused to write a loadable DSO, IMO. Mounting $PGDATA 'noexec' and allowing the postgres user to write only to such noexec mounts sounds like a good layer. It's independent, though - it can be used whether or not the above guarantee holds. > 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 agree now. Thanks for elaborating. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
