On Tue, Oct 5, 2010 at 4:25 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
>> The stronger form is that they shouldn't even be able to tell that
>> hidden rows exist, which is something your view doesn't try to do;
>> but there are at least some applications where that would be
>> desirable.
>
> I can understand that, but from what I've read on the topic, it
> seems that even some of the most security-conscious government and
> military users concede that point and just go with meaningless
> identifiers for inter-table references, so that what leaks is
> meaningless.
Even apart from inter-table references, you can potentially infer
things like table sizes from query response times. But I think that
stuff is just intractable as a database problem. In real world
situations, you can handle it by interjecting massive latency. For
example, if some semi-trusted party asks the US "do you have any
nuclear submarines that are currently near this lat/long?", you can
give them the answer back, say, the next day. At that point it's
pretty hard for them to infer anything about how long it took you to
search your database of nuclear-submarine-locations, which is
information you might want to keep secret for a variety of reasons.
But the amount of latency that you need to insert to provide a safety
valve is going to be highly application-dependent, and in many cases
it's basically "none", as in the sales rep/customer database I
mentioned earlier.
> Some of this seems to fit fairly neatly with the general direction
> in which KaiGai has been pushing; some of it maybe not so much,
> because we don't operate on something as simple as "secret", "top
> secret", etc.
I wouldn't get the particular issue of leaky views confused with
SE-Linux integration. There is definitely a use case out there for
label-based mandatory access control, but I don't think anyone would
deny that it's a small subset of our total user base. Being able to
use views to hide a subset of the rows in some table is a much more
generally useful thing to be able to do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company