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 ofpolyinstantiation [Denning 87]. Polyinstantiation forces a
relationtocontain multiple tuples with the same primary key but distinguishable bytheir classification levels or by the
non-primarykey attributes of therelation [Lunt 91].
which I think we want to avoid. 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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
