Re: Facility for detecting insecure object naming

On Thu, Aug 16, 2018 at 12:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Mark Dilger <hornschnorter@gmail.com> writes:
>> Go ahead and define some new lexical scope mechanism.  I'm probably
>> going to move into the 21st century with you and use it.  (I mostly
>> use "my", not "local", when I write perl code.)  But let's treat that as
>> a new feature independent of fixing the security problems with dynamically
>> scoped variables and privilege escalation attacks.
>
> To my mind, the really fundamental problem here is that our default/
> traditional search_path includes publicly writable schemas.  I don't
> especially care whether you establish your search_path setting
> dynamically, or lexically, or through magic hocus pocus: if it includes a
> schema that a hostile user can create objects in, you'll get pwned sooner
> not later.  So it doesn't seem to me that Robert's proposal is really
> doing much to move the goalposts.  He's presuming that the main problem
> is that user A and user B have different ideas about which schemas are
> trusted ... but I think that that is, at most, a minority use-case.
> I suspect that a system-wide definition of which schemas are trusted
> would serve many installations just fine.

I agree that if this is the sort of thing you are worried about, then
function trust is a reasonable step in a good direction.  It is
definitely the case that letting hostile users put stuff into your
search path provides a large number of ways for them to potentially
pwn you.  I do wonder whether, instead of de-trusting those users, you
ought not to instead deny them the ability to create objects in your
search_path, either by changing their privileges or by changing your
own search path.  But if you can't do that for some reason,
de-trusting executable objects that they create in that search_path is
a good thing to be able to do.

But that's not really where I think the biggest problems are, even
though I agree that those are problems.  In my view, the biggest
problem is that sometimes you may need to write code that works with
any search_path setting.  pg_dump is a good example.  It's got to
iterate through all of the schemas in the system and dump them all.
Extensions are another example.  If you install the earthdistance
extension, it's supposed to work no matter how search_path is set when
the functions it contains get called.  Functions used in defining
expression indexes are another example; you want them to work the same
way no matter what the prevailing search_path happens to be when
tuples are inserted or the table gets reindexed.  As long as it's
straightforward to swap out the search path under which the function
was intended to execute for some other one, stuff is going to break.

Again, this is not an argument against function trust, which I
actually think is a pretty good proposal.  It just doesn't address the
thing I personally consider to be the biggest problem.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company