Re: Updates of SE-PostgreSQL 8.4devel patches - Mailing list pgsql-hackers

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> I am confused how knowing that a sequence number used for a primary key
>>> exists or doesn't exist is leaking _meaningful_ information.  People
>>> might know the sequence number exists, but how is that information
>>> useful.  Now, if natural keys are used, that is a different story.
>> Right.  It might be that securing a database requires not just some
>> security mechanisms but also some database design rules (like "don't
>> allow foreign keys except on synthetic IDs").  But it seems to me that
>> we are just flailing around in the dark because we don't have that
>> bigger picture of how the features would actually get used.
>>
>> The literature pointers that Andrew just gave us seem promising to me.
>> Who's going to go searching for some useful info?
> 
> I found this paper from 1996:
> 
>     http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950
> 
> Full PDF at link in right column.  The interesting chapters are chapter
> 3, that talks about "ENTITY AND REFERENTIAL INTEGRITY IN MLS DATABASES"
> and chapter 4, "COVERT CHANNELS".  It mentions "polyinstantiation":
> 
>     These security considerations have led to the notion of
>     polyinstantiation [Denning 87]. Polyinstantiation forces a relation to
>     contain multiple tuples with the same primary key but distinguishable by
>     their classification levels or by the non-primary key attributes of the
>     relation [Lunt 91].
> 
> which I think we want to avoid.

At the past, I had considered to implement polyinstantiated table
as a part of SE-PostgreSQL, but it required us unacceptable scale
of changes, so I dropped the idea.

> It also talks about cases where the
> primary and foreign key rows have identical or different security
> settings.  It talks about "COVERT CHANNELS", which is information
> leaking.
> 
> And it mentions TCSEC (Trusted Computer System Evaluation Criteria):
> 
>     http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria
> 
> which I think is the proper term for the security target we are trying
> to address, or at least one of the targets.

Yes, TCSEC gives us structured requirement sets categorized into several
security levels.

I introduced a requirement of ISO/IEC15408 in the previous message.
It is a more modern security evaluation criteria, and designed based
on the TCSEC from a historical angle.
So, they have similar requirements.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>