Re: How to get SE-PostgreSQL acceptable

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(at)ak(dot)jp(dot)nec(dot)com>