Re: [v9.4] row level security

2013/9/1 Josh Berkus <josh(at)agliodbs(dot)com>:
> Kaigai,
>
>>> 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.
>
> That's an astonishingly weak argument, because the bandwidth you're
> talking about is still very high, as in *hundreds* or *thousands* of
> values per minute. It's one thing to make the bandwidth argument for
> things like monitoring power draw, where the leakage is one character
> per hour, but the covert channels we're talking about are several orders
> of magnitude faster than that.
>
> So, I repeat: if you continue to pursue the argument that the covert
> channels identified aren't significant because of bandwidth, you will
> doom this patch. The valid arguments are only two:
>
> a) clearly identified use case X doesn't care about covert channels for
> reason Y, and will find RLS extremely useful.
>
> b) we can't fix these covert channels now, but plan to work on them in
> the future, and have ideas for how to approach them.
>
An important point is, what covert-channel should be closed, and what
other covert-channel can be ignored.
Even though the scenario Korotkov reported would be enough to make
us surprised, we may need to consider how wide covert channel should
be closed soon or later.

* A covert-channel that can expose raw-data directly, should be fixed up.
=> Thus, leaky-view problem needed to be fixed.

* A covert-channel that can expose existence of a particular value with
less than Log(N) order trials to the possible range of hidden value.
=> Thus, this scenario needs to be cared?

Or, any other criteria even though?

My (current) preference is plan (c: we will be able to fix up *this*
cover-channel with reasonable efforts on explain code. probably,
we can close it if we don't print filtered rows under the sub-query
with security-barrier attribute.

It does not mean we shall or can fix up any possible covert-channels
being found in the future, however, I also agree that we shall tackle
covert-channel scenario being enough serious; that's criteria may
or may not be bandwidth of information leakage.

>> 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).
>
> To be completely blunt, the security community does not understand
> databases. At all. I'd think if anything had become clear through the
> course of work on SEPosgres, it would be that.
>
>>> 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.
>
> Again, please abandon your bandwidth arguments. They are irrelevant to
> whether or not this patch gets accepted.
>
> So, please try again?
>
>>> 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.
>
> I don't think I understood this answer. What I'm asking is: will
> government agencies be sigificantly more likely to adopt PostgreSQL if
> we have RLS, in this form? Or do we need "military-grade" before it
> makes a difference?
>
Even though I'm not a marketer for public sector, not a small number
of Oracle virtual private database, that provide more simple functionality,
has been accepted for public sectors also, I believe it encourages
adoption of PostgreSQL on government agencies.
However, military division often requires special treatment for security
functionality but very small number of users are interested in, thus,
it is not a good idea to focus on this grade here.

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