Re: Marking some contrib modules as trusted extensions - Mailing list pgsql-hackers

Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Our previous
>> discussions about what privilege level is needed to look at
>> pg_stat_statements info were all made against a background assumption
>> that you needed some extra privilege to set up the view in the first
>> place.  I think that would need another look or two before being
>> comfortable that we're not shifting the goal posts too far.

> While you could maybe argue that's true for pg_stat_statements, it's
> certainly not true for pg_stat_activity, so I don't buy it for either.

The analogy of pg_stat_activity certainly suggests that there shouldn't be
a reason *in principle* why pg_stat_statements couldn't be made trusted.
There's a difference between that statement and saying that *in practice*
pg_stat_statements is ready to be trusted right now with no further
changes.  I haven't done the analysis needed to conclude that, and don't
care to do so as part of this patch proposal.

> The same goes for just about everything else (I sure hope, at least) in
> our extensions set- none of the core extensions should be allowing
> access to things which break our security model, even if they're
> installed, unless some additional privileges are granted out.

Maybe not, but the principle of defense-in-depth still says that admins
could reasonably want to not let dangerous tools get installed in the
first place.

> As such, I really don't agree with this entire line of thinking when it
> comes to our core extensions.  I view the 'trusted extension' model as
> really for things where the extension author doesn't care about, and
> doesn't wish to care about, dealing with our security model and making
> sure that it's followed.  We do care, and we do maintain, the security
> model that we have throughout the core extensions.  

I am confused as to what "entire line of thinking" you are objecting
to.  Are you now saying that we should forget the trusted-extension
model?  Or maybe that we can just mark *everything* we ship as trusted?
I'm not going to agree with either.

>> The bigger picture here is that I don't want to get push-back that
>> we've broken somebody's security posture by marking too many extensions
>> trusted.  So for anything where there's any question about security
>> implications, we should err in the conservative direction of leaving
>> it untrusted.

> This is just going to a) cause our users to complain about not being
> able to install extensions that they've routinely installed in the past,

That's utter nonsense.  Nothing here is taking away privileges that
existed before; if you could install $whatever as superuser before,
you still can.  OTOH, we *would* have a problem of that sort if we
marked $whatever as trusted and then later had to undo it.  So I
think there's plenty of reason to be conservative about the first
wave of what-to-mark-as-trusted.  Once we've got more experience
with this mechanism under our belts, we might decide we can be more
liberal about it.

> and b) make our users wonder what it is about these extensions that
> we've decided can't be trusted to even just be installed and if they're
> at risk today because they've installed them.

Yep, you're right, this patch does make value judgements of that
sort, and I'll stand behind them.  Giving people the impression that,
say, postgres_fdw isn't any more dangerous than cube isn't helpful.

> While it might not seem obvious, the discussion over on the thread about
> DEFAULT PRIVILEGES and pg_init_privs is actually a lot more relevant
> here- there's extensions we have that expect certain functions, once
> installed, to be owned by a superuser (which will still be the case
> here, thanks to how you've addressed that), but then to not have EXECUTE
> rights GRANT'd to anyone (thanks to the REVERT FROM PUBLIC in the
> installation), but that falls apart when someone's decided to set
> up DEFAULT PRIVILEGES for the superuser.  While no one seems to want to
> discuss that with me, unfortunately, it's becoming more and more clear
> that we need to skip DEFAULT PRIVILEGES from being applied during
> extension creation.

Or that we can't let people apply default privileges to superuser-created
objects at all.  But I agree that that's a different discussion.

            regards, tom lane