Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

On Mon, Sep 03, 2012 at 12:11:20AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > I don't think it's libpq's job to enforce security policy this way.  In any
> > event, it has no reason to presume an environment variable is a safer source.
> 
> One easy thing we could do that would at least narrow the risks is to
> only allow the executable's *directory* to be specified, hardwiring the
> executable file name to "postgres" (or "postgres.exe" I guess).

If the user has any interactive access to the machine, he could make a
/tmp/X/postgres symbolic link to the program of his choosing.

> I'm inclined to think though that environment variables *are* more
> secure in this context.  In the contrib/dblink example, such a
> restriction would certainly help a lot.

dblink_connect() should only let superusers specify standalone_datadir at all;
normal users have no business manipulating other data directories visible to
the backend running dblink.  For superusers, setting both standalone_datadir
and standalone_backend is fair game.

Trusting the environment over connection strings is a wrong policy for, say, a
setuid command-line program.  Suppose such a program passes libpq a fixed
connection string to access its embedded database.  The program will find
itself explicitly clearing this environment variable to regain safety.

> In any case, we should at
> least think of a way that an app using libpq can prevent this type
> of attack short of parsing the conn string for itself.

My recommendation to affected application authors is to pass the connection
string through PQconninfoParse().  Walk the array, validating or rejecting
arguments like "host" and "standalone_datadir".  For maximum safety, the
application would need to reject any unanticipated parameters.  We might
soften that by adding a "bool critical" field to PQconninfoOption that
documents whether the option must be understood by a program validating a
connection.  Compare the idea of the PNG chunk header's "ancillary" bit.
Parameters like "host" and "standalone_datadir" would be critical, while
"application_name" and "connect_timeout" would be ancillary.  But this is a
tough line to draw rigorously.


I was pondering the flexibility from letting the application fork/exec and
supply the client-side descriptor number(s) to libpq.  Suppose it wants to
redirect the backend's stderr to a file.  A single-threaded application would
temporarily redirect its own stderr while calling PQconnectdb().  In a
multithreaded application, that introduces a race condition when other threads
concurrently write to the normal stderr.  By handling redirection in its own
fork/exec code, the application can achieve the outcome safely.  Perhaps
offering this can wait until the feature constitutes a more general
embedded-database offering, though.

Thanks,
nm