Skip site navigation (1) Skip section navigation (2)

Re: Updates of SE-PostgreSQL 8.4devel patches

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: (view raw, whole thread or download thread mbox)
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:
> Full PDF at link in right column.  The interesting chapters are chapter
> 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):
> 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.

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-09-27 15:05:21
Subject: Re: PostgreSQL future ideas
Previous:From: Alex HunsakerDate: 2008-09-27 06:53:27
Subject: Re: Auto-explain patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group