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 not necessarily
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 number means 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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
