Skip site navigation (1) Skip section navigation (2)

Re: allowing privileges on untrusted languages

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: allowing privileges on untrusted languages
Date: 2013-01-29 02:36:54
Message-ID: CA+TgmoYfOEAMJF8CmMbKsmhHMYnDV=dpda1HGArh2QTKvFB=5w@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jan 27, 2013 at 11:15 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 01/28/2013 02:15 AM, Robert Haas wrote:
>
> I am not sure whether it's really true that a capability mechanism
> could "never really satisfy" anyone.  It worked for Linux.
>
> I have no concern about using a capabilities approach for this, but I don't
> think Linux is a great example here. Linux's capabilities have been defined
> in a somewhat ad-hoc fashion and a huge amount of stuff is bundled into
> CAP_SYS_ADMIN. Several capabilities provide escalation routes to root /
> CAP_SYS_ADMIN. See:
>
> https://lwn.net/Articles/486306/
> http://dl.packetstormsecurity.net/papers/attack/exploiting_capabilities_the_dark_side.pdf
>
> There's nothing wrong with capability systems, it's just clear that they
> need to be designed, documented and maintained carefully. Adding ad-hoc
> capbilities is exactly the wrong route to take, and will lead us into the
> same mess Linux is in now.
>
> But, I think event triggers are a credible answer, too, and they
> certainly are more flexible.
>
> Yes,  but with the caveat that leaving security design to user triggers will
> provide users with more opportunities for error - failure to think about
> schemas and search_path, testing role membership via some hacked-together
> queries instead of the built-in system information functions, failure to
> consider SECURITY DEFINER and the effect of session_user vs current_user,
> etc. Some docs on writing security triggers and some standard triggers in an
> extension module would go a long way to mitigating that, though. The appeal
> of the trigger based approach is that it means core doesn't land up needing
> CAP_CAN_EXECUTE_PLPERLU_ON_TUESDAYS_AFTER_MIDDAY_ON_A_FULL_MOON_IN_A_LEAPYEAR.

+1 to the entire email, and well said.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-29 02:39:27
Subject: Re: unlogged tables vs. GIST
Previous:From: Robert HaasDate: 2013-01-29 02:34:41
Subject: Re: Enabling Checksums

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group