Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
