Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)

Peter Eisentraut wrote:
> KaiGai Kohei wrote:
>>> I would like to be able to assign SQL-level ACLs and SELinux labels
>>> to the same row at the same time in the same build, and have the
>>> system enforce both on top of each other.
>>
>> In my opinion, it makes more pains (user-interface, performance,
>> complexity
>> of implementation and so on) than its benefit which allows to support MAC
>> and DAC concurrently.
>
> I am a bit surprised. I'd consider the ability to do DAC and MAC
> concurrently to be absolutely essential, for several reasons:
>
> 1. DAC is managed by users, MAC by administrators.
>
> 2. They address different but concurrent use cases.

Yes,
Please note that I don't say it is something worthless.
However, when we implement it with a single security system column,
its demerit is unacceptable.

> 3. Transitioning to MAC will be a lot easier if it doesn't require you
> to drop the DAC configuration all at once.
>
> 4. You don't propose to drop table ACLs if you enable SELinux, do you?
> Same issue.

Yes, management of security attribute is a major work of security features.
Thus, when we switch the active security feature, it does not managed
correctly. Please imagine what is happen when we remount ext3 filesystem
without "acl" flag, or we boot a SELinux'ed system with selinux=0.

> 5. It's possible!

Indeed, it is possible, but it is fact we also have some of trade-offs.
The biggest matter is user-interfaces to modify security attribute is
unclear.

If we have two system column, "security_acl" for DAC and "security_label"
for MAC, it allows to implement the feature without remarkable pains.
Well, we can simply update the "security_acl" to update per tuple ACLs.
However, again, we return to start of the discussion.

Tom said:
> Wait a minute. The original argument for providing SQL-driven row level
> security was that it would help provide a framework for testing the code
> and doing something useful with it on non-selinux platforms.

I think it is not a issue which has perfect answer, so we need to decide
a way to implement it. My preference is 1 security system column and
1 security feature design.

I tried to summarize the proposed options, as follows:

o : merit x : demerit X : unacceptable demerit

* 1 security system column, 1 security feature (DAC or MAC)
o It suitable for a single security system column implementation.
x If a user want to use both of DAC and MAC concurrently, he has
to choose one of them.
o It allows all the security feature on the common framework,
suitable for the original Row-level ACLs purpose.

* 2 security system column, 2 security feature (DAC and MAC)
o It allows both of DAC and MAC consurrently, without remarkable
regressions.
x It needs two new security system columns.
x What is the purpose of the Row-level security in original?

* 1 security system column, 2 security feature
X It gives us catastrophic regression in user-interface, performance
and code complexity. Its merit is trivial compared to its demerit.

--
KaiGai Kohei