Re: Column Redaction

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

In response to

Responses

Browse pgsql-hackers by date

  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