From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extension Templates S03E11 |
Date: | 2013-12-01 14:58:02 |
Message-ID: | m2k3fovcsl.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2013-12-01 14:58:45 | Re: name.c |
Previous Message | Dimitri Fontaine | 2013-12-01 14:48:40 | Re: Extension Templates S03E11 |