Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

A.M. wrote:
>
> On Sep 19, 2008, at 1:42 PM, Robert Haas wrote:
>
>>> It's too early to vote. :-)
>>>
>>> The second and third option have prerequisite.
>>> The purpose of them is to match granularity of access controls
>>> provided by SE-PostgreSQL and native PostgreSQL. However, I have
>>> not seen a clear reason why these different security mechanisms
>>> have to have same granuality in access controls.
>>
>> Have you seen a clear reason why they should NOT have the same
>> granularity?
>>
>> I realize that SELinux has become quite popular and that a lot of
>> people use it - but certainly not everyone. There might be some parts
>> of the functionality that are not really severable, and if that is the
>> case, fine. But I think there should be some consideration of which
>> parts can be usefully exposed via SQL and which can't. If the parts
>> that can be are independently useful, then I think they should be
>> available, but ultimately that's a judgment call and people may come
>> to different conclusions.
>
> If the SE-PostgreSQL effort simply implemented SQL interfaces to
> increase security granularity, it wouldn't be SE-PostgreSQL at all.
> SE-PostgreSQL integrates with a set of optional system-wide access
> controls and is only marginally related to SQL-level database features.
> Since it relies on an optional component, it doesn't really make sense
> that anyone is surprised that the patch doesn't improve security
> granularity of vanilla PostgreSQL.

I understand what you say is the part of decision making should be
pluggable and like a "fine-grained-only" mode should be selectable.
(I'm sorry, if my understanding is incorrect.)

I thought this approach prevents to support various kind of "enhanced"
security mechanism on PGACE security framework.
Do you know SE-PostgreSQL is designed to use common set of security hooks
named as PGACE? It provides bare hooks and minimum facilities to handle
security attribute. The reason why it does not define internal structure
of security mechanism is to avoid to assume specific mechanism.

My preference is to switch whole of security mechanism by configuration
option as SE-PostgreSQL or LSM doing.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>