On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote: > 2013/8/29 Alexander Korotkov <aekorot...@gmail.com>: > > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > >> > >> 2013/8/28 Oleg Bartunov <obartu...@gmail.com>: > >> > btw, there is serious problem with row-level security and constraints. > >> > For > >> > example, user with low security level could use unique constraint to > >> > know > >> > about existence of a row with higher security. I don't know, what is > >> > the > >> > best practice to avoid this. > >> > ... > > > A principle of this row-level security feature is, it prohibits to > leak invisible > datum itself, but might allow users to expect existence of records with > a particular value. In fact, we never push down function that may leak > the given argument, that does not have leakproof attribute, even if it can > be utilized for index-scan. > My opinion is, we should deal with it is "a limitation" of this feature, as > long as it does not expose the raw data to be hidden. Estimation takes > time to carry out much hidden data via covert channel, thus traditional > secure operating system specification with MAC implementation says > its degree of threat is not significant as long as bandwidth of covert > channel is not so much. I think it is a reasonable standpoint. > > Thanks, > -- > KaiGai Kohei <kai...@kaigai.gr.jp> >
Okay, given that argument, how would you monitor such attempts to access data through the covert channel and shut it down? Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers