From: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Updates of SE-PostgreSQL 8.4devel patches |
Date: | 2008-09-27 09:59:53 |
Message-ID: | 48DE0419.3000509@kaigai.gr.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-09-27 15:05:21 | Re: PostgreSQL future ideas |
Previous Message | Alex Hunsaker | 2008-09-27 06:53:27 | Re: Auto-explain patch |