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.
The issue is not such a simple one.
SELinux allows to change its security context, if user has
appropriate privileges (relabelfrom and relabelto).
When a tuple (label=Secret, PK=123) is inserted then it is
relabeled to (label=TopSecret, PK=123), it has to return an
error due to the PK confliction, even if he does not have
permission to refer it.
I guess you already noticed that the previous security research
report about polyinstantiation implicitly assumes a fixed form
security policy, like "higher can read lower", "higher cannot
write lower" and so on.
But, SELinux's security policy does not assume anything.
It always returns its decision based on flexible security policy.
So, polyinstantiation is very difficult technology. :-(
(And will be overspec for enterprise class purpose.)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
