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.