Re: Updates of SE-PostgreSQL 8.4devel patches

Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)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(at)kaigai(dot)gr(dot)jp>