Re: Feature Request on Extensions

On Sun, Aug 18, 2013 at 10:34 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> On 08/18/2013 10:20 PM, Dimitri Fontaine wrote:
>> Hi,
>>
>> I had the chance to being at OSCON this year and had a chat with the
>> Open Shift team while there. Thanks for posting your use case!
>>
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> Right offhand, it seems like you have or could grant a developer
>>> superuser/DBA privileges with respect to his own PG instance, so I'm not
>>> actually seeing why you have a problem. What exactly is stopping him
>>> from installing his extension in the normal way?
>> They use the same binary installation for everyone, and an OS packaged
>> one at that. Which means that there's a single `libdir` and `pkglibdir`
>> shared globally on the system. And no individual user has any privileges
>> down there as it's a global OS location.
>>
>> What they want is to be able to run the same binary for every user, yet
>> have a personal `libdir` place where to load extension's .so files from,
>> and point that to a place owned by the initdb bootstrap superuser,
>> different each time.
>>
>> The easiest way for them here would be for this parameter to be a fully
>> dynamic setting, second best an initdb option, IIUC.
>>
>> The way they make that secure in their model is by using modern
>> approaches to security, or at least modern enough that we don't get to
>> envision those offerings when we usually talk about the idea of allowing
>> the backend to load non-root-owned binary modules: SElinux and CGroups.
> Even without SELinux I can not immediately see the security weakening
> when you allow the backend to load .so-s from directories which are
> owned by the user both the client and the backend runs as.
>
> so say there is system user 'bob' who has his own instance of database
> initdb-ed in /home/bob/pgsql and running as user bob, with bob also being
> the "main" superuser for the cluster.
>
> User bob can then CREATE EXTENSION which loads .so-s from
> /home/bob/libpgsql
> and if a more restricted user is needed for web client database access
> then bob can do CREATE USER lesserbob; for this.
>
> I think this is something that should be secure even with standard
> non-SELinux install.
>
> Feel free to point out where a security escalation is possible with such
> a use case.

The escalation happens because in a normal system-wide installation of
PostgreSQL as you'd see on most production systems will have the
installation directories and binaries owned by the root user, so if
the server or a superuser account on it is compromised, the attacker
still can't (easily) modify the PostgreSQL installation to do Bad
Things, assuming the sysadmin has disabled untrusted PLs.

I can see the use case for the change suggested, but I feel pretty
strongly that it should not be allowed in a default configuration, and
should be something that can be disabled from outside of
postgresql.conf (which of course, can often be modified through
PostgreSQL by a superuser - and yes, I realise there is risk there
too, but no sense adding to that).

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company