Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>> 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?
>
> The reason it's a problem for SE-Postgres is that the entire row-level
> security feature is advertised on the premise that it allows you to
> hide the existence of data; a claim not made by regular SQL. If the
> feature doesn't do what it's claimed to do then it's fair to ask why
> have it.
I've never said SE-PostgreSQL hide the existence of invisible tuples.
It just filtered out violated tuple from result set, but it is not
same as hiding the existence.
In other word, it does not care about covert channels as I repeated
many times.
The purpose of row-level access control is to provide users more
flexibility in their security configuration, not to eliminate
covert channels.
For example, if PostgreSQL has no SELinux support, we have to set up
multiple instance for each security domain to ensure data separation,
but it also gives us a restriction when we want to share a data from
multiple domains.
(Please note that it is talked from the viewpoint of SELinux.)
When it got SELinux support in table level granularity, we can integrate
them into a single instance, since SE-PostgreSQL ensure correct access
controls in this level, but it still disallow to store them into a single
table.
When it got row-level granularity, we can integrate them stored within
separated tables into a single one with correct access controls.
It is also a reason why I accepted to separate row-level feature in
the v8.4 development.
Again, it is not a target for SE-PostgreSQL to eliminate covert channels.
It is same as major commercial databases with row-level granularity.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>