Re: Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL)

[Andy Warner <warner@rubix.com>]

[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]



KaiGai Kohei wrote:
> KaiGai Kohei wrote:
>   
>> My preference is the later one:
>>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>
>> In addition, an idea of configuration file can be considerable to set up
>> the default context of database objects, though I considered it is not
>> necessary in the past discussion.
>> If a user want to work the database server process as an unconfined domain,
>> like a legacy "disable_xxxx_trans" boolean doing, the <server context> as
>> the target of TYPE_TRANSITION breaks all the correct labeling.
>>
>> If we have a /etc/selinux/$POLICYTYPE/contexts/db_{sepgsql|rubix}, as follows,
>> it can be used to specify the default context of special purpose database
>> object such as schemas to store temporary database objects, not only the
>> context of database as the root of type transition.
>> ------------
>> database    *             system_u:object_r:sepgsql_db_t:s0
>> schema      pg_temp_*     system_u:object_r:sepgsql_temp_schema_t:s0
>>   :             :            :
>> ------------
>>
>> The libselinux has selabel_lookup(3) interface to implement them
>> for various kind of objects.
>>     
>
> The attached patch is a proof of the concept.
> It adds the forth backend of selabel_lookup(3) interface.
>
> Under the enhancement, we should the following rules to determine what
> security context is assigned on the newly created database object.
>
> 1. An explicitly specified security context by users.
>    e.g)  CREATE TABLE t (a int, b text)
>              SECURITY_LABEL = 'system_u:object_r:sepgsql_table_t:SystemHigh';
>
> 2. A matched entry in the configuration file which can be lookup up
>    by selabel_lookup(3).
>    e.g)  schema  pg_temp_*  system_u:object_r:sepgsql_temp_schema_t:s0
>                  ^^^^^^^^^ --> if the new object name and type are matched.
>
> 3. The result of security_compute_av() or avc_compute_create() which can
>    return the result of TYPE_TRANSITION rules.
>
> The second step is newly suggested in this patch.
> Needless to say, the determinded security context has to be checked
> by the security policy.
>
>   
>> One concern is performance hit. If we need to open/lookup/close the file
>> for each INSERT statement, its pain will be unacceptable.
>>     
>
> This patch does not support db_tuple class, because of headach in performance
> and its characteristic that database tuples have no name to identify itself.
>   
Good decision about not including the tuple. I'm guessing that without
the tuple, the lookup would generally have small impact on overall
performance.

Is it standard in SELinux to have the selabel_lookup have higher
priority over any type transition rule? I was always curious about that.
> Thanks,
>   

[-- Attachment #2: Type: text/html, Size: 3298 bytes --]