From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Thom Brown <thom(at)linux(dot)com>, Damian Wolgast <damian(dot)wolgast(at)si-co(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Claudio Freire <klaussfreire(at)gmail(dot)com> |
Subject: | Re: Column Redaction |
Date: | 2014-10-15 18:46:04 |
Message-ID: | CA+TgmoYOYtUyvKZHmgAXDs7ZeuTnEuhMnX30EUxA0LbmwAGBpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 15, 2014 at 4:04 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 14 October 2014 17:43, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Oct 11, 2014 at 3:40 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-10-15 18:55:25 | Re: group locking: incomplete patch, just for discussion |
Previous Message | Tomas Vondra | 2014-10-15 18:02:30 | Re: Yet another abort-early plan disaster on 9.3 |