Re: Updates of SE-PostgreSQL 8.4devel patches - Mailing list pgsql-hackers

Robert Haas wrote:
>>> I think you have to resign yourself to the fact that a user who can
>>> see only a subset of the rows in a table may very well see apparent
>>> foreign-key violations.  But so what?
>> So you're leaking information about the rows that they're not supposed
>> to be able to see.  This is not what I would call national-security-grade
>> information hiding --- leastwise *I* certainly wouldn't store nuclear
>> weapon design information in such a database.  The people that the NSA
>> wants to defend against are more than smart enough, and persistent
>> enough, to extract information through such loopholes.
> 
> If your plan is to refuse to implement row-level security until
> someone produces a design that can never leak information under any
> circumstances regardless of how the user configures it, then I
> strongly suspect we'll be waiting forever.  The designs being put
> forward here are capable of being configured in an insecure fashion,
> but that's true of any other security mechanism we offer, too.

In my understanding, security evaluation criteria does not require
to prevent such kind of information leaks (called as illicit information
flow, or covert channel) in all cases.

The ISO/IEC15408 is a set of specifications for security functionalities
of IT products. We can find its requirement about illicit information flow
as follows:

- FDP_IFF.3  Limited illicit information flows, requires the SFP             to cover illicit information flows, but
notnecessarily             eliminate them.
 
- FDP_IFF.4  Partial elimination of illicit information flows, requires             the SFP to cover the elimination of
some(but not necessarily             all) illicit information flows.
 
- FDP_IFF.5  No illicit information flows, requires SFP to cover the             elimination of all illicit information
flows.
 (*) FDP_IFF = Functionalities of Data Protection               Information Flaw control Functions (*) The larger tail
numbermeans more strict requirement. (*) Common Criteria part.2 at
http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R2.pdf

At least, we can say it is not something like "all or nothing".

> SE-PostgreSQL needs to be good enough for the NSA, but row-level
> security in general does not.

BTW, it seems to me someone misunderstand I works as an agent of NSA.
Is it a humor, itn't it? I've paid my effort to improve the security
of open source software, not for overseas intelligence agency.

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