>> 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.
Please note that the security policy has to allow the client db_xxxx:{create}
privilege on creation of database object independent from its labeling
strategy. Don't confound the way to specify an explicit label and permission
to create a database object. :-)
>From an analogy of filesystem, if we can put a valid security context on
/proc/self/attr/fscreate, it enables us to *try to create* a file with
discretionary label, but it does not mean that the file:{create} permission
is always allowed on any given labels.
Thanks,
--
KaiGai Kohei <kaigai@xxxxxxxxxxxx>
--
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.
