Re: Column Redaction

On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> As soon as you issue the above query, you have clearly indicated your
> intention to steal. Receiving information is no longer accidental, it
> is an explicit act that is logged in the auditing system against your
> name. This is sufficient to bury you in court and it is now a real
> deterrent. Redaction has worked.

To me, this feels thin.  It's true that this might be good enough for
some users, but I wouldn't bet on it being good enough for very many
users, and I really hope there's a better option.  We have an existing
method of doing data redaction via security barrier views.  There are
information leaks, to be sure, but they are far more subtle and
low-bandwidth than Rod's query.  The reason for that is that only
trusted code (leakproof functions) are allowed to run against the
trusted data; the redaction is applied before any
potentially-untrustworthy stuff happens.  Here, you're applying the
redaction as the very last step before sending the data to the user,
and that allows too much freedom to do bad stuff between the time the
database first lays hands on the data and the time it gets redacted.

But maybe that can be fixed.  I don't know exactly how.  I think you
need a design that allows you to restrict very tightly the operations
that an untrusted user can perform on trusted data.  Maybe you only
want to allow "=" and nothing else, for example.  Perhaps the set of
allowable predicates could be defined via DDL.  Then when the query is
run, the system imposes a security fence.  Only approved predicates
can be pushed through the fence.  And when the data crosses the fence
from the trusted side to the untrusted side, redaction happens at that
point, rather than just before sending the data to the user.

This is, of course, more complicated.  But I think it's likely to be
worth it.  The problem with relying on auditing is that you need a
human to look at the audit logs and judge intent.  With a query as
overt as Rod's, that's maybe not too hard.  But with a lot of analysts
running a lot of queries, it might not be that hard to bury an
information-stealing query inside an innocent-looking query in such a
way that the administrator doesn't notice.  Granted, that's playing
with fire, but I've encountered many security vulnerabilities in my
career that can be exploited without doing anything obviously evil.
If you retroactively put a packet-sniffer on every network I've ever
been connected to, and carefully examined all my network traffic,
you'd find me finding holes in all kinds of things, but in fact,
nobody's ever noticed a problem in advance of me reporting it.

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