Robert Haas wrote:
On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane <t...@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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
