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,
|
