Re: [v9.4] row level security

2013/9/3 Bruce Momjian <bruce(at)momjian(dot)us>:
> On Sun, Sep 1, 2013 at 11:05:58AM -0700, Josh Berkus wrote:
>> > 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.
>
> Agreed. The security community realizes these covert channels exist,
> but doesn't really have any recommendations on how to avoid them. You
> could argue that avoiding them is too tied to specific database
> implementations, but there are general channels, like insert with a
> unique key, that should at least have well-defined solutions.
>
The security community also provides an extreme solution, but I don't
think it is suitable for flexible security policy and PostgreSQL wants it.

Their "extreme" solution manipulate definition of PK that automatically
become combined key that takes user-given key and security level being
set mandatory.
Thus, it does not conflict even if two different users with different security
level tries to insert a row with same primary key.
This technology is called polyinstantiation.
http://en.wikipedia.org/wiki/Polyinstantiation

However, of course, I'm not favor to port this technology to PostgreSQL
world. Its side-effects are too much towards the problem to be solved.

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