2013/9/3 Bruce Momjian <br...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
