Обсуждение: Feature Request on Extensions
Greetings all:
I spoke to Josh B and company at OSCON about a feature we really need for PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service).
What we need is the ability for Postgresql to load extensions from a users file space. For example, if, as a developer on a machine, I wanted to load PostGIS into PostgreSQL, I should be able to (either at DB start, Cluster Initiatialization, or from within the psql command line) specify an additional path where PostgreSQL can look for the binaries for extensions. Compile time is not an acceptable solution UNLESS, that compile time parameter can be an environment variable that is present for all users but points to different locations. This feature would be turned on or off at the whole database level.
I know that under a typical server install scenario this would be a bad from a security perspective, but on OpenShift we runs things differently. Let me explain what happens when a developer creates an application on OpenShift:
1) Each developer application on OpenShift is actually a unique user on the Linux machine.
2) That user is locked down very tight using SELinux and CGroups to create a container like environment.
3) We then start up an instance of PostgreSQL server running as that unique user. If there are 30 applications using Postgresql on that node in our OpenShift cluster then there will be 30 instances of Postgresql running on the machine each as a different userid. But the binary they start from is the single binary that is laid down in the OS. Therefore everyone is starting from the same binary and they share all the binaries.
4) The developer does not have permissions to add binaries (or any files) to locations other /home/<uniqueuserid>/app-root/data and a PAM namespaced /tmp. So even while a user could probably download all the pieces necessary to compile an extension they have no way to actually write the binaries for the extension to the correct Postgresql file location.
What this means for OpenShift is that the we have to approve, package, and maintain any extension that a user wants to use. But we don't want to have that relationship between the developer and their Postgresql extensions. Given our security model we don't care what extension they want to run (as long as they don't violate the TOS).
So what we really need is the ability to tell Postgresql - "yup it is fine for a user to install an extension - especially if they server is running as the same user trying to install the extension - so go ahead and look in this directory for any possible extensions"
I hope this all makes sense. I also realize this will take some time to make it into Postgresql, but I think multi-tenant systems are going to become more and more common in the future.
Thanks and I look forward to the discussion...
Steve
On Sat, 2013-08-17 at 17:53 -0400, Steven Citron-Pousty wrote: > What we need is the ability for Postgresql to load extensions from a > users file space. Sure, that would be useful for a number of reasons. I think there was a proposed patch for that a while ago that some people objected to, so that might need to be revised a little. But it sounds doable.
On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote:
There were objections earlier against loading anything "binary" fromGreetings all:I spoke to Josh B and company at OSCON about a feature we really need for PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service).What we need is the ability for Postgresql to load extensions from a users file space.
a directory not being writable by root only.
But allowing loading modules from the directory of the user the server
runs as (usually postgres, but could be any system user other than root)
seems like a really good idea.
I can not see how this would create any additional security problems,
as the user can already do anything that user can do. adding postgresql
binary in this mix running as the same user can not possibly add any
new security concerns.
If anybody can point out something I overlook here, please do so!
Cheers
-- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
On 08/18/2013 11:36 AM, Hannu Krosing wrote:
On 08/17/2013 11:53 PM, Steven Citron-Pousty wrote:There were objections earlier against loading anything "binary" fromGreetings all:I spoke to Josh B and company at OSCON about a feature we really need for PostgreSQL extensions on OpenShift (Red Hat's Platform as a Service).What we need is the ability for Postgresql to load extensions from a users file space.
a directory not being writable by root only.
But allowing loading modules from the directory of the user the server
runs as (usually postgres, but could be any system user other than root)
seems like a really good idea.
I can not see how this would create any additional security problems,
as the user can already do anything that user can do. adding postgresql
binary in this mix running as the same user can not possibly add any
new security concerns.
To be extra sure no additional security is breached, CREATE EXTENSION could
add check that the client requesting this is also the same user connected
locally via ident authentication when requesting loading binary modules from
this users (who is running both postgresql binary and client) owned filespace.
-- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
Steven Citron-Pousty <spousty@redhat.com> writes:
> What we need is the ability for Postgresql to load extensions from a
> users file space.
TBH this needs a whole lot of thought. I'm prepared to grant that there
may be other useful security models besides the one we currently have,
but we need to be sure that anything we offer as an alternative is secure
on its own terms and well-thought-out.
The main problem that I'm having with the idea ATM is that I don't see
how we could allow any such capability to non-superusers; isn't the
ability to load chosen code into the server tantamount to superuserdom?
If we restrict it to superusers, and the capability is only effective
for the current session, that seems like it will lead directly to
people running their whole application as superuser. Which is a place
we don't want to end up at, no matter what the security model is.
So I think that you've underspecified "a user" --- there needs to be
some separation between users who have the ability to create/activate
extensions and users who can use those extensions.
> I know that under a typical server install scenario this would be a bad from a security perspective, but on OpenShift
weruns things differently. Let me explain what happens when a developer creates an application on OpenShift:
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?
regards, tom lane
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@sss.pgh.pa.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. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
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@sss.pgh.pa.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. Regards, -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ
On Sun, Aug 18, 2013 at 10:34 PM, Hannu Krosing <hannu@2ndquadrant.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@sss.pgh.pa.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
Dave Page <dpage@pgadmin.org> writes: > 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 appreciate that line of arguments, but it's been proven more than once (last time by Andres) to be just false. Given a malicious user with superuser privileges on a standard PostgreSQL backend without any extension nor PL installed, arbitrary code execution is already possible and quite easy to achieve. Given how easy it is, that whole line of thoughs really is moot. > 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). My proposal here would be in the lines of a dynamic GUC where you could add directories to consider at LOAD time (including .so dependencies resolution, that's the main trick). That GUC would default to being empty, which should answer your valid concern here. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Mon, Aug 19, 2013 at 10:21 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Dave Page <dpage@pgadmin.org> writes: >> 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 appreciate that line of arguments, but it's been proven more than once > (last time by Andres) to be just false. Given a malicious user with > superuser privileges on a standard PostgreSQL backend without any > extension nor PL installed, arbitrary code execution is already possible > and quite easy to achieve. > > Given how easy it is, that whole line of thoughs really is moot. If you find a hole in the boat, the preferred option is to fix it, not to say "meh, well another won't hurt". >> 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). > > My proposal here would be in the lines of a dynamic GUC where you could > add directories to consider at LOAD time (including .so dependencies > resolution, that's the main trick). That GUC would default to being > empty, which should answer your valid concern here. That wouldn't address my concern, which is preventing someone with only DB server superuser access from enabling the feature. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave Page <dpage@pgadmin.org> writes: > If you find a hole in the boat, the preferred option is to fix it, not > to say "meh, well another won't hurt". My understanding is that there's no way to fix it. If you're superuser you have the keys to the kingdom. That's it. And that's why it's very important that as many as possible of our feature set works without requiring superuser. > That wouldn't address my concern, which is preventing someone with > only DB server superuser access from enabling the feature. There's nothing I've heard of allowing you to think implementing a restricted security access for superusers is ever going to fly. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Mon, Aug 19, 2013 at 11:34:47AM +0200, Dimitri Fontaine wrote: > Dave Page <dpage@pgadmin.org> writes: > > If you find a hole in the boat, the preferred option is to fix it, not > > to say "meh, well another won't hurt". > > My understanding is that there's no way to fix it. If you're superuser > you have the keys to the kingdom. That's it. > > And that's why it's very important that as many as possible of our > feature set works without requiring superuser. That's pretty vague. Exactly what does "keys to the kingdom" mean? If it means you can do anything to the database, you are right. If it means executing arbitrary code, including arbitrary kernel calls, I would like to hear how that is done. Was writing into the postgres users's .profile and waiting for them to log in what you were thinking of? You could also create a binary in their home directory and have .profile run it. (I thought this was a particularly creative exploit.) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes: > That's pretty vague. Exactly what does "keys to the kingdom" mean? If > it means you can do anything to the database, you are right. If it > means executing arbitrary code, including arbitrary kernel calls, I > would like to hear how that is done. You've now heard about one way to do that in an off-list email, so that it's not in our public archives for any malicious user to find it. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Mon, Aug 19, 2013 at 11:44:36PM +0200, Dimitri Fontaine wrote: > Bruce Momjian <bruce@momjian.us> writes: > > That's pretty vague. Exactly what does "keys to the kingdom" mean? If > > it means you can do anything to the database, you are right. If it > > means executing arbitrary code, including arbitrary kernel calls, I > > would like to hear how that is done. > > You've now heard about one way to do that in an off-list email, so that > it's not in our public archives for any malicious user to find it. Yes, agreed. FYI, the method I listed above is public and was discovered on an exploit website. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +