2013/9/3 Bruce Momjian <bruce@momjian.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@kaigai.gr.jp>