Re: SE-PostgreSQL and row level security

Greg Stark wrote:
> On Mon, Feb 16, 2009 at 4:14 PM, Robert Haas <robertmhaas@gmail.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.