Re: Extension Templates S03E11

Jeff Davis <pgsql@j-davis.com> writes:
>> 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.

It does answer if only superusers are allowed to install SECURITY
INVOKER templates, which I forgot to add in the previous email. Or at
least my understanding is that it could work that way.

> 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.

Yes that's a simpler model. And simpler is better when talking security.

The only drawback of that is to forbid the superuser from executing a
command. That would be new in PostgreSQL I think. We can work around
that with automating the SET ROLE to the template owner when a superuser
is creating the extension. That's what led me to the SECURITY DEFINER
proposition.

Either of those solution are fine to me, with or without the automated
SET ROLE when a superuser is installing an extension from a template
owned by a non-superuser.

Tell me your preference, I'll work on the code.

>> 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?

I still think about extensions as being a per-database thing, and that
the current security policy makes if a per-major-version thing when the
extension contains a module (.so).

Also, the dynamic_library_path already allows us to make binary
extensions a per-database object again, baring incompatibilities that
would manifest themselves as run-time errors…

So I strongly vote against making the Extension Templates a set of
shared catalogs.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support