Re: API change advice: Passing plan invalidation info from the rewriter into the planner?

On 6/11/14, 10:26 AM, Robert Haas wrote:
> Now, as soon as we introduce the concept that selecting from a table
> might not really mean "read from the table" but "read from the table
> after applying this owner-specified qual", we're opening up a whole
> new set of attack surfaces. Every pg_dump is an opportunity to hack
> somebody else's account, or at least audit their activity.

I'm in full agreement we should clearly communicate the issues around
pg_dump in particular, because they can't necessarily be eliminated
altogether without some major work that's going to take a while to
finish. And if the work-around is some sort of GUC for killing RLS
altogether, that's ugly but not unacceptable to me as a short-term fix.

One of the difficult design requests in my inbox right now asks how
pg_dump might be changed both to reduce its overlap with superuser
permissions and to allow auditing of its activity. Those requests
aren't going away; their incoming frequency is actually rising quite
fast right now. They're both things people expect from serious SQL
oriented commercial database products, and I'd like to see PostgreSQL
continue to displace those as we reach feature parity in those areas.

Any way you implement finer grained user permissions and auditing
features will be considered a new attack vector when you use those
features. The way the proposed RLS feature inserts an arbitrary
function for reads has a similar new attack vector when you use that
feature.

I'm kind of surprised to see this turn into a hot button all of the
sudden though, because my thought on all that so far has been a giant so
what? This is what PostgreSQL does.

You wanna write your own C code and then link the thing right into the
server, so that bugs can expose data and crash the whole server? Not
only can you shoot yourself in the foot that way, we supply a sample gun
and bullets in contrib. How about writing arbitrary code in any one of
a dozen server-side languages of wildly varying quality, then hooking
that code so it runs as a trigger function whenever you change a row?
PostgreSQL is *on it*; we love letting people write some random thing,
and then running that random thing against your data as a side-effect of
doing an operation. And if you like that...just wait until you learn
about this half-assed rules feature we have too!

And when the database breaks because the functions people inserted were
garbage, that's their fault, not a cause for a CVE. And when someone
blindly installs adminpack because it sounded like a pgAdmin
requirement, lets a monitoring system run as root so it can watch
pg_stat_activity, and then discovers that pair of reasonable decisions
suddenly means any fool with monitoring access can call
pg_file_unlink...that's their fault too. These are powerful tools with
serious implications, and they're expected to be used by equally serious
users.

We as a development community do need to put a major amount of work into
refactoring all of these security mechanisms. There should be less of
these embarrassing incidents where bad software design really forced the
insecure thing to happen, which I'd argue is the case for that
pg_stat_activity example. And luckily so far development resources are
appearing for organizations I know of working in that direction
recently, as fast as the requirements are rising. I think there's a
good outcome at the end of that road.

But let's not act like RLS is a scary bogeyman because it introduces a
new way to hack the server or get surprising side-effects. That's
expected and possibly unavoidable behavior in a feature like this, and
there are much worse instances of arbitrary function risk throughout the
core code already.

--
Greg Smith greg(dot)smith(at)crunchydatasolutions(dot)com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/