Re: SE-PostgreSQL and row level security

Greg Stark wrote:
> On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I'm not sure I understand what you mean by that. I expect that if I
>> deny a particular user access to SELECT from a particular table the
>> system will throw a permissions error if that user later enters
>> "SELECT * FROM <table-name>". I don't expect that the system will
>> foresee every possible alternative way that a user might able to infer
>> something about the contents of that table and block it. I similarly
>> expect that if I install SE-PostgreSQL and configure it to filter out
>> certain rows from accesses to certain tables, those rows will in fact
>> be filtered. I still don't expect it to foresee every possible
>> alternative way that a user might be able to infer something about the
>> contents of the data to which the user does not have direct access.
>>
>> Is this fundamentally a semantic issue? If there's an asymmetry here
>> in what is being claimed, I'm not seeing it.
>
>
> Well the asymmetry is that in the former case the verb is "deny" and
> the latter it's "filter"...

I had talked to some knowledgeable people involved in designing
operating system security systems about this. A major design principle
for adding "advanced" security features was to minimize the impact on
existing interfaces.

This makes a lot of sense here. The problem is that in SQL you can
uniquely address columns, but not rows. So to avoid getting permission
denied errors in the face of column-level privileges, you simply omit
the off-limits columns from the select list and restriction clauses.
You mostly do this anyway, selecting only the columns that you are
legitimately interested in. So the interface impact is low. With
row-level privileges, you can't do that. Using the "deny" approach,
you'd immediately get permission denied errors for almost all queries in
your application as soon as you start setting row-level restrictions.
The fix would be to change all queries to add a restriction clause to
get only the rows you have access to. So the interface impact would be
pretty high. With a "filter" approach, the impact is much lower.

As you try to SELinux or SEWhatever-equip a complete operating system,
including kernel, file system, networking, X windows, etc., you have to
apply this deny vs filter tradeoff over and over again, to avoid
upsetting existing interfaces.

So, according to my state of knowledge, the purpose of row-level
security is actually *not* primarily to hide the existence of
information, but merely to hide the information itself under a standard
access-control mechanism while minimizing the impact on existing interfaces.