Just to intoduce myself, I'm Marc Munro the developer of Veil, a
postgres add-in that allows you to implement virtual private databases
using views.
The problem we are discussing here is the existence of covert or
side-channels being available from functions that can leak information
about the rows they see, even though the end-user may not see those
rows. These can be built-ins such as set_config() (thanks, Heikki) or
user-defined.
I assert that any attempt to use a secured-view's where-clause
conditions before any other conditions are applied will lead to poor
performance.
Here is a typical veil secured view definition:
create view parties as
SELECT party_id, client_id, party_type_id, username, party_name
FROM parties.parties
WHERE api.user_has_client_or_personal_privilege(client_id, party_id,
'selectparties')
OR api.user_has_client_privilege(party_id, 'select clients');
A typical query against this would be:
select * from parties where party_id = 42;
The conditions in the view's where clause cannot generally be indexed.
Applying those conditions before the user-supplied conditions would mean
that a full-table scan would be required and performance would suck. In
fact, this very suckiness also exposes a covert channel in that now we
can use the performance of the query to estimate the number of party
records.
The most acceptable solution I have heard so far for this issue, is to
identify those functions which can leak information as 'insecure', and
those views which are for security purpose as 'secured'. Then it is
simply (hah!) a matter of planning the query of secured views so that
all insecure functions are called after all secure functions. In this
way, they will only be able to leak what the user is entitled to see,
and performance will only be as badly affected as is strictly necessary.
__
Marc
