Re: [v9.4] row level security

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>, 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-30 10:05:42
Message-ID: CADyhKSW_o2nVWFytdTY84DUXZSuZkD_EtY2d8wAjR18UruOXYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/8/29 Josh Berkus <josh(at)agliodbs(dot)com>:
> Kaigai,
>
>> 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.
>
> Why are you assuming a human needs to do it? Given the explain vector,
> I could write a rather simple python or perl script which would find
> values by EXPLAIN leakage, at 1000 explain plans per minute.
>
> It's one thing to day "we can't solve this covert channel issue right
> now in this patch", but saying "we don't plan to solve it at all" is
> likely to doom the patch.
>
> I'm not sure what the solution would be, exactly. Deny permission for
> EXPLAIN on certain tables?
>
> Surely someone in the security community has discussed this?
>
Security community considers covert channel is a hard to solve problem;
nearly impossible to eliminate.
Let's see the summary in wikipedia:
http://en.wikipedia.org/wiki/Covert_channel

It does not require countermeasure of covert channels in middle or entry
class security evaluation; that is usually required for enterprise grade,
even though it is required for the product being designed for military
grade.
The reason why its priority is relatively lower, is that degree of threats
with information leakage via covert channel has limited bandwidth in
comparison to main channel.

I also follow this standpoint; that is enough reasonable between
functionality and its strictness under limited resources.
Even if we could close a certain channel, we never can all other
channels, like a signal by namespace contention on table creation
as covert channel. Also, I don't know major commercial dbms handles
these scenario well.

Of course, it should be described in the document for users not to
apply these security features onto the region that overs our capability.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-08-30 10:13:46 Re: [v9.4] row level security
Previous Message Thom Brown 2013-08-30 09:48:47 Re: Statement timeout logging