<div dir="ltr">Any constraints could be "covert channel".<br /></div><div class="gmail_extra"><br /><br /><div
class="gmail_quote">OnWed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai <span dir="ltr"><<a
href="mailto:kaigai@kaigai.gr.jp"target="_blank">kaigai@kaigai.gr.jp</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/8/28 Oleg Bartunov <<a
href="mailto:obartunov@gmail.com">obartunov@gmail.com</a>>:<br/><div class="im">> btw, there is serious problem
withrow-level security and constraints. For<br /> > example, user with low security level could use unique
constraintto know<br /> > about existence of a row with higher security. I don't know, what is the<br /> > best
practiceto avoid this.<br /> ><br /></div>It is out of scope for this feature. We usually calls this type of
information<br/> leakage "covert channel"; that is not avoidable in principle.<br /> However, its significance is
minor,because attacker must know identical<br /> data to be here, or must have proving for each possible values.<br />
Itssolution is simple. DBA should not use value to be confidential as unique<br /> key. If needed, our recommendation
isalternative key, instead of natural key,<br /> because its value itself does not have worth.<br /><br /> I should add
anote of caution onto the documentation according to<br /> the previous consensus, however, I noticed it had gone from
thesgml files<br /> while I was unaware. So, let me add description on the documentation.<br /><div class="HOEnZb"><div
class="h5"><br/> Thanks,<br /> --<br /> KaiGai Kohei <<a
href="mailto:kaigai@kaigai.gr.jp">kaigai@kaigai.gr.jp</a>><br/></div></div></blockquote></div><br /></div>
