Re: 8.4 release planning - Mailing list pgsql-hackers

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> Tom Lane wrote:
>>> The second problem is that we're not sure it's really the right thing,
>>> because we have no one who is competent to review the design from a
>>> security standpoint.
> 
>> Are we underestimating Kaigai Kohei?
> 
> Perhaps he walks on water, but still I'd like to have more than one
> person who has confidence that this design and implementation are correct.
> 
>> and it seems his patches there related to postgresql were pretty widely
>> discussed on the SELinux lists:
>>   http://www.nsa.gov/research/selinux/list-archive/0805/index.shtml#26163
> 
> Well, a quick look through that thread shows a lot of discussion of the
> selinux policy code that's in the patch, which is good as far as it goes
> because for sure there's no one in *this* list who understands a line of
> that stuff.  But to be blunt there's no evidence there that anyone in
> that discussion has heard of a foreign key, much less understands why
> it might be an issue for this patch.  I see a lot of reasoning by
> analogy to X servers, and little if any database-specific knowledge.

I believe they understand the issues related to covert channels (via PK/FK)
and polyinstantiation, though it is not talked on the thread.
(NOTE: The origin of poluinstantiation is previous security research!)
Yes, there is indeed no evidence. If so, it is a good idea to ask
their opinion with SELinux folks (expect for me?).

As I noted before several times, there are several classes in security
requirements. Historically, TSCEC (Trusted Computer System Evaluation
Criteria, Orange-Book) is a representative evaluation criteria for
security features in IT producets. Now it is inherited to ISO/IEC15408
called as CC (Common Criteria).
We can also consider CC as a set of security functional requirements,
and it defined various kind of requirements.

An interaction between foreign keys and invisible rows is a kind of
covert channel issue. Indeed, it has a possibility users to infer
existance of invisible tuples.
In ISO/IEC15408, FDP_IFF (Information Flow Function, Functionality
of Data Protection) section describes about related requirements.
It defines various classes of requirements. One highest stuff requires
to eliminate all the information-flows via covert-channel, but others
does not require to eliminate at all, or does not mention about it.
Here, it is important what requirement are choosen depends on a
sort of evaluated product, environment, estimated-threat and so on.

NOTE: Oracle Label Security does not care about covert-channels,     because it may also compound for FK/PK issues and
row-level    security.     http://www.commoncriteriaportal.org/files/epfiles/20080306_0402b.pdf
 

In the previous discussion, we (including me) decided that SE-PostgreSQL
also does not care about the FK/PK issues, because polyinstantiation feature
needs unacceptable widespread reworks on PostgreSQL, so I added an explicit
text in the documentation to notice its restriction for end-users.

At least, earlier commercial database (Oracle) does not care, and it can
follow ISO/IEC15408 manner, so I think it is fair enough approach.
It is a summary of previous discussion.

Joshua, Chad, please comment anything, if my understanding was incorrect.

BTW, I have not walked on water yet.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>