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. 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. 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) 2) do we plan to reduce the accessibility of data via covert channels over successive releases? How? 3) will accepting this patch allow our users in the Government space to more freely adopt PostgreSQL? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
