On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
> Granted, the "internalization" of the DSO is somewhat critical to
> implement. Running as a non-root user, Postgres has less power than that
> and can certainly not protect the internalized DSO from modification by
> root. It can, however, store the DSO well protected from other users
> (e.g. in a directory within $PGDATA).
There's heaps of problems with that though. Think noexec mounts or selinux.
> Relying on the external DSO only exactly once can provide additional
> safety.
Not necessarily. Think of a distribution provided upgrade with a
security fix in an extension. On a machine with dozens of clusters. Now
you need to make sure each and every one of them has the new .so.
> Consider an extensions directory that's accidentally
> world-writable. As it stands, an attacker can modify the DSO and gain
> control as soon as a new connection loads it. With my proposal, the
> attacker would have to wait until CREATE EXTENSION. A point in time
> where the newly created extension is more likely to be tested and
> cross-checked.
I think protecting against the case where such directories are writable
is a rather bad argument. If anything screwed up those the postgres
binaries directory itself quite likely has also been changed and such.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services