Re: allowing privileges on untrusted languages

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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services