Re: [v9.4] row level security

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [v9.4] row level security
Date: 2013-08-29 14:35:54
Message-ID: CADyhKSUD7qdQeTndZ6mDpp05V6MnRBzQO1FmYBq1+Zp37oyRrg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/8/29 ktm(at)rice(dot)edu <ktm(at)rice(dot)edu>:
> On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
>> 2013/8/29 Alexander Korotkov <aekorotkov(at)gmail(dot)com>:
>> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> >>
>> >> 2013/8/28 Oleg Bartunov <obartunov(at)gmail(dot)com>:
>> >> > btw, there is serious problem with row-level security and constraints.
>> >> > For
>> >> > example, user with low security level could use unique constraint to
>> >> > know
>> >> > about existence of a row with higher security. I don't know, what is
>> >> > the
>> >> > best practice to avoid this.
>> >> >
> ...
>> >
>> A principle of this row-level security feature is, it prohibits to
>> leak invisible
>> datum itself, but might allow users to expect existence of records with
>> a particular value. In fact, we never push down function that may leak
>> the given argument, that does not have leakproof attribute, even if it can
>> be utilized for index-scan.
>> My opinion is, we should deal with it is "a limitation" of this feature, as
>> long as it does not expose the raw data to be hidden. Estimation takes
>> time to carry out much hidden data via covert channel, thus traditional
>> secure operating system specification with MAC implementation says
>> its degree of threat is not significant as long as bandwidth of covert
>> channel is not so much. I think it is a reasonable standpoint.
>>
>> Thanks,
>> --
>> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
>>
>
> Okay, given that argument, how would you monitor such attempts to access
> data through the covert channel and shut it down?
>
Although I didn't touch this task by myself, my senior colleague said that we
calculated some possible bandwidth of leakage as an evident when we ship
supercomputer system with MAC feature for customer who worry about security.
I'm not sure how to measure it. However, if we assume a human can run up to
5 query per seconds, he needs 2-3 seconds to identify a particular integer value
less than 10000, it means bandwidth of this covert channel is less than 5bps.
I'm not sure whether enterprise-grade dbms has to care about these amount
of covert channel.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-08-29 14:39:09 Re: Support for REINDEX CONCURRENTLY
Previous Message ktm@rice.edu 2013-08-29 14:23:21 Re: [v9.4] row level security