Martijn van Oosterhout wrote:
> On Mon, Feb 16, 2009 at 11:10:19AM +0900, KaiGai Kohei wrote:
>> At the previous discussion, two items were pointed out.
>>
>> The one is called as covert channel. When a tuple with PK is refered by
>> one or more tuples with FK, row-level control prevents to update or delete
>> the PK, even if the FK is invisible from users. It allows users to infer
>> existence of invisible FK.
>
> One thing I keep missing in this discussion: the term "row-level
> security" in the above senstence in not the important part. Right now
> you can revoke SELECT permission on a table with a foreign key and it
> will still prevent UPDATEs and DELETEs of the primary key, allowing
> users to infer the existance of an invisible FK.
>
> This is the same "covert channel", so why is it a problem for
> SE-Postgres and not for normal Postgres?
Please note that I don't consider it is a problem, even if SE-PostgreSQL.
Both of SE-PostgreSQL and vanilla PostgreSQL don't give an assurance to
eliminate information leaks via such kind of covert channels, so they
don't violate any specifications of them. Thus, it is not a problem.
When we revoke SELECT permission on FK table, user cannot select on
the table directly. It surely follows the specification as documented.
In generally, security requirements depend on its environment in use,
value of information asset to be managed and so on.
If a user really needs to eliminate covert channels, he can choose
a product which gives an assurance for them.
However, it has a tradeoff in closed source, expensive price, not
widely used and so on. :)
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>