Bruce Momjian wrote:
> Tom Lane wrote:
>> Gregory Stark <stark@enterprisedb.com> writes:
>>> I don't think partitioning is really the same thing as row-level
>>> security.
>> Of course not, but it seems to me that it can be used to accomplish most
>> of the same practical use-cases. The main gripe about doing it via
>> partitioning is that the user's nose gets rubbed in the fact that there
>> can't be an enormous number of different security classifications in the
>> same table (since he has to explicitly make a partition for each one).
>> But the proposed implementation of row-level security would poop out
>> pretty darn quick for such a case, too, and frankly I'm not seeing an
>> application that would demand it.
>
> OK, putting on my crazy idea hat, if we split the primary and foreign
> keys by partition, it would give us polyinstantiation:
>
> http://en.wikipedia.org/wiki/Polyinstantiation
>
> because our unique indexes do not apply across partitions.
> Polyinstantiation is a desirable security feature and one that would be
> tough to implement without partitions.
>
Polyinstantiation in this manner won't do it I don't think (if I'm understanding
you correctly). As KaiGai already said, SELinux policy is flexible so we'll have
more than just BLP policy to worry about.
Also a top secret user will need to see all rows when he selects, and they
should still have unique keys. He won't be able to write to secret or unclass
rows but he'll be able to see them.
Further, a secret user may be able to see top secret rows, but not some of the
columns, going back to my coordinates example. He'd have to use a trusted stored
procedure that can do the necessary operations to fuzz the data.
A flexible policy is really the crux of this. We aren't trying to reproduce what
other DBMS's have done, we are trying to integrate with a completely flexible
policy from the ground up.
