Re: [v9.4] row level security - Mailing list pgsql-hackers

2013/8/29 Alexander Korotkov <aekorotkov@gmail.com>:
> On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>
>> 2013/8/28 Oleg Bartunov <obartunov@gmail.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.
>> >
>> It is out of scope for this feature. We usually calls this type of
>> information
>> leakage "covert channel"; that is not avoidable in principle.
>> However, its significance is minor, because attacker must know identical
>> data to be here, or must have proving for each possible values.
>> Its solution is simple. DBA should not use value to be confidential as
>> unique
>> key. If needed, our recommendation is alternative key, instead of natural
>> key,
>> because its value itself does not have worth.
>>
>> I should add a note of caution onto the documentation according to
>> the previous consensus, however, I noticed it had gone from the sgml files
>> while I was unaware. So, let me add description on the documentation.
>
>
> I think there is another "covert channel" much more serious than constrains.
> You can gather information about hidden data by reading query plans.
>
> CREATE TABLE test (id SERIAL PRIMARY KEY, value INTEGER);
> INSERT INTO test (value) VALUES (1234), (4321), (2356), (6542);
> ALTER TABLE test SET ROW SECURITY FOR ALL TO (id % 2 = 1);
> CREATE INDEX test_idx ON test (value);
>
> User sees only 1 and 3 rows:
>
> postgres=> select * from test;
>  id | value
> ----+-------
>   1 |  1234
>   3 |  2356
> (2 rows)
>
> But user can probe values column using explain command.
>
> postgres=> set enable_seqscan = off;
> SET
> postgres=> explain analyze select * from test where value between 1111 and
> 3333;
>                                                   QUERY PLAN
> ---------------------------------------------------------------------------------------------------------------
>  Index Scan using test_idx on test  (cost=0.13..8.16 rows=1 width=8) (actual
> time=0.021..0.024 rows=2 loops=1)
>    Index Cond: ((value >= 1111) AND (value <= 3333))
>    Filter: ((id % 2) = 1)
>  Total runtime: 0.056 ms
> (4 rows)
>
> postgres=> explain analyze select * from test where value between 1111 and
> 5555;
>                                                   QUERY PLAN
> ---------------------------------------------------------------------------------------------------------------
>  Index Scan using test_idx on test  (cost=0.13..8.16 rows=1 width=8) (actual
> time=0.020..0.024 rows=2 loops=1)
>    Index Cond: ((value >= 1111) AND (value <= 5555))
>    Filter: ((id % 2) = 1)
>    Rows Removed by Filter: 1
>  Total runtime: 0.057 ms
> (5 rows)
>
> In given example user can realize that there is a hidden value in index
> between 3334 and 5555. Using dichotomy he can find exact value.
> I didn't find if there was discussion about it. This example is only my
> first idea about using plans for probing hidden values. Probably, there are
> some other ways to do it.
>
Hmm. It is a new scenario for me, even though its basis is similar to
the scenario that abuses constraints because it still does not leak
the hidden value itself and it requires "estimation" by human.

If we tackle this issue, an easy solution is to hide "rows removed by
filter" output if plan is underlying sub-query plan that was constructed
by row-level security feature.

> I don't think we can say that indexed data is not sensitive for leakage.
> Prohibiting push down of all operators which could be used for such kind of
> attacks also doesn't seem acceptable for me because of huge impact to
> performance. Another option I see is to hide some sensitive parts of plan
> from unprivileged user. There is still a room for timing attack, but it
> doesn't seem to be feasible in practice to apply.
>
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@kaigai.gr.jp>