Re: Proof of concept: standalone backend with full FE/BE protocol

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Mon, Sep 03, 2012 at 12:11:20AM -0400, Tom Lane wrote:
>> 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 said "narrow", not "eliminate" ;-)

>> 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.

> 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.

Well, a program that was concerned with this would *already* want to
clear every environment variable that affects libpq, else its database
connections could get redirected somewhere surprising. libpq already
provides enough infrastructure to get the list of such variables ... but
only ones that are associated with connection string parameters. So for
this purpose, making the standalone-control parameters not be accessible
through connection strings would actually be worse.

>> 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.

Even more to the point, we can't seriously expect application authors to
know what to do with connection parameters that didn't exist when they
were writing their code. Every new security-critical parameter would
represent a new set of bugs.

I'm reluctantly coming to the conclusion that we can't pass these
parameters through the regular libpq connection string mechanism, and
will have to invent something else. That's awfully nasty though;
it will pretty much cripple the idea that this would be a simple way to
invoke a quasi-embedded variant of Postgres.

regards, tom lane