Re: SE-PostgreSQL Specifications

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SE-PostgreSQL Specifications
Date: 2009-07-27 23:14:01
Message-ID: 4A6E34B9.2030402@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chris Browne wrote:
> sam(at)samason(dot)me(dot)uk (Sam Mason) writes:
>> On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
>>> Robert Haas wrote:
>>> In some cases, the clearance of infoamtion may be changed. We often
>>> have dome more complex requirements also.
>> OK, so there is some other trusted entity that has unfettered access to
>> both databases and its job is to manage these requirements.
>
> No, that's not what this implies.
>
> What this implies is along the following lines...
>
> If a user at the "more secret" level updates some data that had been
> classified at a lower level, then that data gets reclassified at the
> higher level.
>
> If this sort of outcome is problematic, then that suggests that maybe
> the attempt at sharing wasn't such a good idea.

Theoretically, such kind of updates are not visible for lower security
level users. In other word, a tuple can have multiple version depending
on the security level, it might be called as polyinstantication.

However, SE-PostgreSQL and SELinux which provides the security policy
adopt more simple solution. Its security policy prevent any "writer"
operations on the data object which dose not have identical security
level.

In other word, if the database client has "classified" level.
He cannot write anything on both of "unclassified" and "secret",
but it is possible for "classified" data object.

>>> Thus, it is necessary a capability to store and manage data objects
>>> with different security labeles in a single database instance here.
>>> (If we don't want to use commercial solutions instead.)
>> SE-PG is about doing the above in one database and allowing more
>> rigorous checks to be done?
>
> I don't think the issue is so much about "more rigorous"; it's about
> having mandatory labelling that is handled consistently.

Yes, it shall perform correctly as far as SE-PostgreSQL manages security
context of database objects and makes its access control decision without
any exceptions.

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 Jeff Davis 2009-07-27 23:18:12 Re: WIP: Deferrable unique constraints
Previous Message Tom Lane 2009-07-27 23:12:31 Re: WIP: Deferrable unique constraints