Skip site navigation (1) Skip section navigation (2)

Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date: 2008-09-24 04:02:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Multilevel frameworks have concepts of data hiding and data substitution 
>> based on labels.  That is, if a user doesn't have permissions on data, 
>> he's not merely supposed to be denied access to it, he's not even supposed 
>> to know that the data exists.  In extreme cases (think military / CIA use) 
>> data at a lower security level should be substitited for the higher 
>> security level data which the user isn't allowed.  Silently.
> Yeah, that's what I keep hearing that the spooks think they want.
> I can't imagine how it would play nice with SQL-standard integrity
> constraints.  Data that apparently violates a foreign-key constraint,
> for example, would give someone a pretty good clue that there's
> something there he's not being allowed to see.

Please note that SE-PostgreSQL does not adopt following technology
because of its complexity. When user tries to update a PK refered by
invisible FK, it generate an error. Thus, it is theoretically possible
to estimate the invisible PKs by attacks with repeating.

In extream case, a technology called as "polyinstantiation" is used.

It allows several tuples with different security level to have same
primary key. When a higher-level user updates a tuple with lower
security level, DBMS makes a new tuple with higher-level and the original
one is kept unchanged. It does not prevent to leak a infomation belonging
with higher security level.

IIRC, FK has to refer a PK with same or lower security level to keep
consistency of its visibility in polyinstantiated tables. If a lower
level user modifies a PK with in same level, DBMS makes a copy of PK
with higher-level. This operating does not affect higher FKs, but
FK integrities are kept.

OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2008-09-24 04:03:00
Subject: Re: stored procedure
Previous:From: chetan NDate: 2008-09-24 03:53:05
Subject: stored procedure

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group