Re: Extension Templates S03E11

On Sat, 2013-11-30 at 23:03 +0100, Dimitri Fontaine wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> >> When a superuser CREATE EXTENSION against a template that has been
> >> provided by a non-privileged user, automatically SET ROLE to that user
> >> before doing so, avoiding escalation privileges.
> >
> > That proposal is worded like a special case for superusers, and I don't
> > see why. If the security model is that an extension script is run with
> > as the template owner, then we should just do that universally. If not,
> > making a special case for superusers undermines the security of
> > powerful-but-not-superuser roles.
>
> I like that idea yes.

To clarify, I wasn't proposing that, I'd just like some consistent
security model.

> So maybe we should have “SECURITY DEFINER” and “SECURITY INVOKER”
> extension templates, the default being “SECURITY DEFINER”?

That doesn't seem to answer Heikki's stated concern, because a malicious
non-superuser would just declare the trojan extension to be SECURITY
INVOKER.

As I see it, the problem is more about namespacing than anything else.
It's analogous to a shell which includes the current directory in the
$PATH -- a malicious user can just name an executable "ls" and trick
root into executing it. The solution for a shell has nothing to do with
setuid; so I'm reluctant to base our solution on SECURITY DEFINER.

I prefer a solution that prevents the kind of name collisions that would
trick a privileged user. My strawman idea was to just say that an
extension template created by a non-superuser could only be instantiated
by that same user.

> Also consider multi-tenancy installations. Certainly, you don't want any
> database owner to be able to review PL code from any other database
> owner in the same cluster when each database owner is another customer.

That could be solved by permissions, as well, right?

Regards,
Jeff Davis