From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, bogdan(at)omnidatagrup(dot)ro, David Fetter <david(at)fetter(dot)org>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PostgreSQL and row level security |
Date: | 2009-02-17 02:30:24 |
Message-ID: | 499A2140.5030004@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Mon, Feb 16, 2009 at 10:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2009-02-17 02:54:24 | Re: SE-PostgreSQL and row level security |
Previous Message | Bruce Momjian | 2009-02-17 02:28:43 | Re: pg_migrator and handling dropped columns |