On Sat, 2013-11-30 at 23:03 +0100, Dimitri Fontaine wrote:
> Jeff Davis <pgsql@j-davis.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