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:
> 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
> And it mentions TCSEC (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
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.
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2008-09-27 15:05:21|
|Subject: Re: PostgreSQL future ideas|
|Previous:||From: Alex Hunsaker||Date: 2008-09-27 06:53:27|
|Subject: Re: Auto-explain patch|