On Fri, Aug 30, 2013 at 04:24:06PM -0400, Stephen Frost wrote:
> > The scenario I'm worried about is where somebody says "hey, Postgres has
> > RLS now, I can rely on that to hide my sooper sekrit data from other users
> > in the same database", and later they have a security breach through some
> > covert-channel attack. Are they going to blame themselves? No, they're
> > gonna blame Postgres. Or consider the case where some bozo publishes
> > a method for such an attack and uses it to badmouth us as insecure.
>
> In my experience, issues are discovered, patched, and released as
> security updates. Does adding RLS mean we might have more of those?
> Sure, as did column level privileges and as does *any* such increase in
> the granularity of what we can provide security-wise.
Releasing a feature we think is perfect, and finding out later is isn't,
and fixing it, is not the same as releasing a feature we _know_ isn't
perfect, and having no idea how to fix it.
From later discussions, it seems like we have to accept that we will
never be able to avoid all convert channels, e.g. timing queries, but we
can avoid the most obvious ones, e.g. EXPLAIN, and improve it as we go.
Knowing there is no end to improving it does make some people feel
uncomfortable, and I can't think of another feature we have added with
such an open-ended nature. We do have open-ended performance features,
but here is seems the value of the feature itself, security, is not
attainable. Perhaps reasonable security is attainable.
I am not saying we should reject this feature --- just that the calculus
of how we decide to add this feature doesn't fit our normal analysis.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
