Re: How to get SE-PostgreSQL acceptable

Bruce Momjian wrote:
> Joshua Brindle wrote:
>>> The big problem is that the security value on system tables controls the
>>> _object_ represented by the row, while on user tables the security value
>>> represents access to the row.  That is just an odd design, and why a
>>> regular system table security value makes sense, independent of the
>>> row-level security feature.
>>>
>> I may not be understanding this but I don't see why. In SELinux everything is an 
>> object, and all objects have contexts. No access is specified on the object or 
>> in the context, that is all done in the policy currently loaded in the security 
>> server. system tables and user tables shouldn't be treated differently 
>> implementation wise, they should just have a context and defer the decision 
>> making to the policy.
>>
>> In practice the system tables (and rows within the tables) would have a context 
>> that restricts access tightly, but this is up to the policy, not the implementation.
>>
>>> FYI, it is possible we might implement row-level security a different
>>> way in 8.5.
> 
> Seeing a pg_attribute row and seeing the column referenced by the row
> are not the same thing.

Yes, it is quite different. It seems to me we are now confusing.

Are you saying: a) SELECT attname FROM pg_attribute where attrelid='t'::regclass and attname='a';  and b) SELECT a FROM
t;
are different, aren't you?

Yes, it is not same thing.

For the query a), SE-PostgreSQL should check db_column:{getattr} permission
on the selected tuples, when row-level security is available.
In this case, it also checks db_column:{select} permission on the
"attname" column and db_table:{select} on the "pg_attribute" table.

For the query b), SE-PostgreSQL checks db_column:{select} permission on
the column "a", and it also checks db_table:{select} on the table "t".
And db_tuple:{select} permission when row-level security is available.

Please note that it checks db_column:* class permission on tuples within
pg_attribute system catalog, although db_tuple:* class ones are applied
on user defined tables.

When it checks permission of column, for example, it requires a label
assigned to the target object. In this case, an object is a row within
pg_attribute system catalog. It needs to be labeled as a column.
Thus, we have to add a field to hold its security label within pg_attribute
system catalog.

My concern is INSERT/UPDATE/DELETE these system catalogs by hand.
When user tries to insert a tuple without explicit security context,
it is necessary to be labeled as default one.
But, if it has variable length form, we have to deform the given
HeapTuple once then form HeapTuple again with text variable.
If it has fixed length oid, we can put it directly, as "oid" doing
at heap_insert() or heap_update().

> Also, we are discussing system catalog values, (table, column,
> function), etc, so I don't see an performance issue.  I haven't heard of
> anyone complaining about our ACL parsing overhead recently.  A cache
> could still be used, but on the text string, not the oid.

Yes, performance is not the first issue here.
The variable length type makes hard to assign a newly inserted tuple
(into pg_class, etc...) a default security context.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>