Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> Bruce Momjian wrote:
>>> Tom Lane wrote:
>>>> KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
>>>>> Bruce Momjian wrote:
>>>>>> I assume that could just be always enabled.
>>>>> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
>>>>> rest of enhanced security features (includes the row-level ACL) are
>>>>> disabled automatically, as we discussed before.
>>>> It seems like a pretty awful idea to have enabling sepostgres take away
>>>> a feature that exists in the default build.
>>> Agreed.
>> I don't agree. What is the reason why? It has been unclear for me.
>>
>> The PGACE security framework is designed to allow users to choose
>> an enhanced security mechanism from some of provided options.
>> (Currently, we have sepgsql and rowacl.)
>> It is quite natural that one is disabled when the other is enabled.
>>
>> If a specific enhanced security mechanism has a privileged position,
>> it should not be a guest of the security framwork, and be hardcoded
>> like existing table-level database ACLs.
>>
>> Again, I don't oppose the Row-level ACLs to be the default selection.
>> However, it should be a selectable option.
>
> I understand, but imagine how this is going to interact for users. What
> happens if I install an SE-Linux binary and point it at a /data
> directory that was not created by SE-Linxu binary. How is the SE-Linux
> binary going to interpret the security field?
When SE-PostgreSQL binary fetch a tuple without its security attribute,
it considers the tuple has an alternative one called as "unlabeled_t".
This behavior is same as when we mount an unlabled filesystem on SELinux
system.
> What happens if I load a non-SE-Linux data dump into a SE-Linux binary?> Do I lose my security settings?
It is same as normal INSERT case. When user gives a data without specific
security context, SE-PostgreSQL assigns it a default security context.
In the default security policy, it is "sepgsql_table_t".
> I am starting to think we should have two optional security fields, one
> for SQL and one for SE-Linux. The big downside of that is that we are
> back to the case of the having lots of SE-Linux-specific code to handle
> that SE-Linux field, rather than reusing the SQL-row-level security
> field.
It is just an idea. If Row-level ACL feature is *hardcoded* (not a guest
of PGACE), is it considerable a hidden attribute typed as "aclitem[]"?
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>