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

[Andy Warner <warner@rubix.com>]

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



KaiGai Kohei wrote:
>>> It had been a headache what is the target of TYPE_TRANSITION for the root
>>> object.
>>> At the initial design, as you pointed out, I used the domain of server
>>> process as the target to decide the security context of database itself.
>>> Then, I got a suggestion that we can use the following notation to
>>> represent the security context of new object is determined by only
>>> the context of subject.
>>>
>>>   TYPE_TRANSITION <subject context> <subject context> : <class> <new context>;
>>>
>>> I could understand as an analogy of permission checks on the kernel
>>> capability classes.
>>>
>>>   
>>>       
>> It seems if you decide the context of the database using only the 
>> subject's attributes itself, there will always be potential conflict 
>> with other DBMS's. There is nothing in the type transition that 
>> identifies the rule as applying to a sepostgresql dbms as opposed to any 
>> other. It seems a bad way to do it. I would propose either:
>>
>> TYPE_TRANSITION <server context> <server context> : <class> <new context>;
>>
>> or
>>
>> TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>>
>> Where the 1st has the potential to cover all permutations (but only one new context) and the latter opens the possibility to have different new contexts based upon the context of the subject, but could leave some permutations uncovered. I think the second case is more general and flexible and the first case could be viewed as a special case of the second.
>>     
>
> I can understand your concern. Indeed, the combination of client context and
> itself cannot handle the case when multiple DBMSs are installed.
>   
Won't the issue exist even if SEPostresql is not installed, as the
policy transition rules (client context and itself) are still there by
default? Or, did you mean if the DBMS policy is installed? I guess one
solution for me could have been to uninstall the sepostgresql policy
module (?).
> My preference is the later one:
>   TYPE_TRANSITION <subject context> <server context> : <class> <new context>;
>   
This one is also my preference.
> 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.
>
> One concern is performance hit. If we need to open/lookup/close the file
> for each INSERT statement, its pain will be unacceptable.
>   
I agree it's interesting but potentially a performance hit. For my
purposes, I don't see this as needed because once the db object
transition rule is settled in a way that is friendly to all DBMS's, all
of the functionality I need exists (at this time). It would be
interestung to know the extend of the performance hit expected.
> Thanks,
>   

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