Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> Stephen Frost wrote:
>> It does seem weird to simply omit records rather than throw an error
>
>> The presumption is that if you know the data exists but can't access it
>> directly, you'll use indirect methods to derive what it is. But if you
>> don't even know it exists, then you won't look for it.
>
> Right, which is why it's bad for something like a foreign key constraint
> to expose the fact that the row does exist after all.
>
Once again, this is not an issue for us. We would much rather have a database
that allows you to hide data from unauthorized clients using a mandatory policy
than one that does nothing because you couldn't close some covert channels.
I'll repeat what I said in an earlier email, SELinux doesn't (and can't) address
all covert channels in Linux, and that is fine as long as it is understood and
documented (which is part of the evaluation process).
>> There's a level above that which I don't think SEPostgres implements,
>> which is data substitution, in which you see different data according to
>> what security level you are. While this may seem insane for a business
>> application, for military-support applications it makes some sense.
>
> I think it might be possible to build such a thing using views, but I
> agree that the patch doesn't give it to you for free.
>