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

2013/8/30 Josh Berkus <josh@agliodbs.com>:
> On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
>
>>> 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
>
> Well, in each of the cases covered in that article, the given technology
> (OSI, TCP, etc.) takes specific provisions to limit the ability of
> attackers to discover information via the covert channel.
>
> However, we have yet to talk about taking any such provisions with
> Postgres.  If we commit this patch, arguably we'll have a row-level
> security feature which only protects data from well-behaved users, which
> seems counterproductive.
>
The point we shouldn't forget is information leakage via covert-channel
has less grade of threat than leakage via main-channel, because of
much less bandwidth.
Security community also concludes it is not avoidable nature as long
as human can observe system behavior and estimate something, thus,
security evaluation criteria does not require eliminate covert-channels
or does not pay attention about covert-channels for the products that
is installed on the environment with basic robustness (that means,
non-military, regular enterprise usage).
I don't think PostgreSQL goes into military-grade secure database
system. If so, it has to sacrifice many thing (like, performance,
usability, nature of open source, ...) for security. It's not a fact.

> So, arguments in favor of this patch:
> a) it's as good as Oracle's security features, giving us "check-box
> compliance".
> b) it allows securing individual rows against attackers with limited
> technical knowledge or limited database access, and could be very
> hardened in combination with intelligent access control.

Even if attacker has enough knowledge, the ratio they can estimate
hidden values is very limited because of much less bandwidth of
covert channels.

> c) it is an improvement on techniques like Veil (is it)?
> d) we plan to continue improving it and closing covert channels, or
> limiting their bandwidth.
>
> Arguments against:
> m) covert channels are currently broad enough to make it trivially
> circumventable (are they?)
> n) overhead and code maintenance required is substantial
>
> So, determinative questions:
>
> 1) are the security mechanisms supplied by this patch superior in some
> way to approaches like Veil for multi-tenant applications?  (this is a
> serious question, as multi-tenant applications are far less concerned
> about covert channels)
>
Yes. This RLS implementation targets the environment that does not
have requirement for a particular bandwidth upperbound on covert-
channels. It allows to centralize the place where we have to care
about access control on main-channel, so it well fits multi-tenant
applications.

> 2) do we plan to reduce the accessibility of data via covert channels
> over successive releases?  How?
>
Less covert channels is better than massive, if we could close it with
reasonable cost; that means run-time performance, code complexity
and so on.
However, in general, it is impossible to eliminate anything in spite of
less degree of threats because of smaller bandwidth. So, I don't think
this is an issue to spent much efforts to solve.

> 3) will accepting this patch allow our users in the Government space to
> more freely adopt PostgreSQL?
>
Government has two spaces. Most of their environment requires similar
requirement as enterprise grade system doing. On the other hand,
military environment often requires upper-bound of covert channel,
as a story I introduce on upthread, but they are minority and have
budget to develop special purpose database system designed for
security with first priority.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>