Re: SE-PostgreSQL and row level security

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>

In response to

Browse pgsql-hackers by date

  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