Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> Multilevel frameworks have concepts of data hiding and data substitution
>> based on labels. That is, if a user doesn't have permissions on data,
>> he's not merely supposed to be denied access to it, he's not even supposed
>> to know that the data exists. In extreme cases (think military / CIA use)
>> data at a lower security level should be substitited for the higher
>> security level data which the user isn't allowed. Silently.
>
> Yeah, that's what I keep hearing that the spooks think they want.
> I can't imagine how it would play nice with SQL-standard integrity
> constraints. Data that apparently violates a foreign-key constraint,
> for example, would give someone a pretty good clue that there's
> something there he's not being allowed to see.
Please note that SE-PostgreSQL does not adopt following technology
because of its complexity. When user tries to update a PK refered by
invisible FK, it generate an error. Thus, it is theoretically possible
to estimate the invisible PKs by attacks with repeating.
In extream case, a technology called as "polyinstantiation" is used. http://en.wikipedia.org/wiki/Polyinstantiation
It allows several tuples with different security level to have same
primary key. When a higher-level user updates a tuple with lower
security level, DBMS makes a new tuple with higher-level and the original
one is kept unchanged. It does not prevent to leak a infomation belonging
with higher security level.
IIRC, FK has to refer a PK with same or lower security level to keep
consistency of its visibility in polyinstantiated tables. If a lower
level user modifies a PK with in same level, DBMS makes a copy of PK
with higher-level. This operating does not affect higher FKs, but
FK integrities are kept.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
