Re: Facility for detecting insecure object naming

On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger <hornschnorter(at)gmail(dot)com> wrote:
> I think you are interpreting the problem too broadly. This is basically
> just a privilege escalation attack vector.

Hmm. Well, I think you're interpreting the problem too narrowly. :-)

In my view, the problem isn't just that there is a risk of privilege
escalation; in fact, for many users, that's not a serious problem at
all because the database has only one user anyway. I think that the
core problem is that you can easily write code that looks like it will
work just fine and then have it not work at all. For example,
somebody:

- creates an SQL or PL/plgsql function
- uses it to define a functional index
- runs REINDEX with a different search path
- gets an error because there's some unqualified or ambiguous
reference inside the SQL function

There might be a security risk here if the REINDEX is run by a
different user with elevated privileges, because then maybe one of the
references inside the SQL or PL/plgsql function could be captured by a
new and malicious object injected into the alternative search path,
but that's not really the point. The point is that you might
reasonably want this to WORK AS INTENDED, not just fail to be
insecure. If your house gets hit by lightning and, as a result, your
alarm system goes offline, you do have a potential security problem,
but also, every appliance in your house is probably fried, and your
house may be on fire. Focusing on the security system specifically is
likely the wrong approach.

So here. What we want, I think, is a way to create the SQL or
PL/pgsql function in such a way that it knows what search path was
intended and uses that search path for the SQL that occurs within it.
Then, the security problem goes away, but even better, the code works.

This is also my basic complaint about the TRUST mechanism: it's not a
bad idea, but it seems to me to be tackling the problem from the wrong
end. If somebody tries to make it so that when I run pg_dump they
hack superuser, having pg_dump error out is surely better than letting
them hack superuser. However, having pg_dump error out, while surely
better than a privilege compromise, is also not great, because I now
don't have a backup. In a sense, I haven't eliminated the security
vulnerability at all; I've just reduced the consequences from
hack-superuser to deny-successful-backup. But deny-successful-backup
is still a pretty bad consequence. What I really want is for pg_dump
to succeed in giving me a correct backup, without compromising
security. Similar with an attack on any other application.

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