Robert Haas wrote:
> On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I haven't seen anyone present a shred of evidence that this would be
>>> the case in SE-PostgreSQL.
>> Sorry, but the burden of proof is in the other direction.
>>
>> In any case, this was already discussed in detail in previous threads.
>> It's possible that you could make the database adequately secure given
>> appropriate design rules, such as "only use synthetic keys as foreign
>> keys". (For instance consider Kevin's example of needing to hide the
>> case caption. If the caption had been used directly as PK then he'd
>> have a problem.) We have seen no evidence that anyone has a worked-out
>> set of design rules that make a SE-Postgres database secure against
>> these issues, so the whole thing is pie in the sky.
>
> I agree that it would be useful to have some documentation that
> outlines the new covert channels that this creates (by virtue of
> blocking the overt channels), approaches to addressing those that can
> be addressed, and warnings about those that can't. I think the only
> ones we've been able to come up with so far are:
I agree. It is important to show users its specification, limitation
and practical workaround explicitly.
However, I think it is not necessary to enumerate all the cases of
covert channels. It is even impossible to define clearly.
What we can do is to introduce a few representative scenarios and
workarounds, and put a notification to use your own risk.
If necessary, I can make a documentation patch?
This is an aside:
The administration guide of Oracle Label Security simply ignores
these discussion. I guess they understand how the matter is difficult.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>