>> 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.
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.
One concern is performance hit. If we need to open/lookup/close the file
for each INSERT statement, its pain will be unacceptable.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@xxxxxxxxxxxxx>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
