On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
> 2013/8/29 Alexander Korotkov <aekorotkov@gmail.com>:
> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> >>
> >> 2013/8/28 Oleg Bartunov <obartunov@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 <kaigai@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
