On Wed, Oct 15, 2014 at 4:04 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 14 October 2014 17:43, Robert Haas <robertmh...@gmail.com> wrote: >> 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. > > I agree with "thin". There is a leak in the design, so let me coin the > phrase "imprecise security". Of course, the leaks reduce the value of > such a feature; they just don't reduce it all the way to zero. > > Security barrier views or views of any kind don't do the required job. > > We are not able to easily classify people as Trusted or Untrusted. > > We're seeking to differentiate between the right to use a column for > queries and the right to see the value itself. Or put another way, you > can read the book, you just can't photocopy it and take the copy home. > Or, you can try on the new clothes to see if they fit, but you can't > take them home for free. Both of those examples have imprecise > security measures in place to control and reduce negative behaviours > and in every other industry this is known as "security". > > In IT terms, we're looking at controlling and reducing improper access > to data by an otherwise Trusted person. The only problem is that some > actions on data items are allowed, others are not.
Sure, I don't disagree with any of that as a general principle. I just think we should look for some ways of shoring up your proposal against some of the more obvious attacks, so as to have more good and less bad. -- 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