On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers