Re: How to get SE-PostgreSQL acceptable - Mailing list pgsql-hackers

If we add a field on pg_xxxx to store security label in text form,
it is necessary to attach a default one at the following points.

* pg_class  - InsertPgClassTuple() at heap.c

* pg_attribute  - InsertPgAttributeTuple() at heap.c

* pg_proc  - ProcedureCreate() at pg_proc.c

* pg_database  - createdb() at dbcommands.c

* for whole of them  - InsertOneTuple() at bootstrap.c  - ExecInsert() at execMain.c

The reason why I prefer security identifier ("oid") is that we can put
a hook to assign a default security context inside the simple_heap_insert().
But, if above functions are the all to insert a new tuple into these
issued relations, it may be a reasonable approach for those four system
catalogs. Please point out if I overlooks somewhere.

At the previous message, I noted I'll submit revised patches on thie
Wednesday, but it become impossible due to the change. (T-T)
Please wait for a while.

KaiGai Kohei wrote:
> 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>