Re: Adding support for SE-Linux security

David P. Quigley wrote:
> On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
> [snip...]
>> I can say from experience that this project is very skeptical of
>> frameworks that aren't accompanied by at least one, and preferably
>> multiple, working implementations. So there is a bit of a chicken and
>> egg problem here. What can sometimes work is to say, look, here's a
>> place where I can put a hook and later I will do something complex
>> with it but here are a couple of relatively simple but useful examples
>> to get started. The examples form the justification for the commit
>> because they are independently useful, but they are much simpler than
>> what the framework may eventually end up being used for.
>>
>> I don't believe that this approach is feasible for SE-PostgreSQL. A
>> simple version of label security is still going to be very
>> complicated, and there are probably even fewer customers for such a
>> thing than there are for SE-PostgreSQL.
>>
>
> Ok if it is a chicken and egg problem then we need to find a smaller
> egg. I agree that having a huge patch set isn't ideal which is why I
> understand the desire to have KaiGai cut back his patches. However the
> patches he is putting forward from what I've gathered have no row based
> labeling and no MAC enforcement. I can understand if you want to cut
> back the object model so you're not mediating every object in the system
> but cutting those two features make it unusable by the customers we have
> who want to use it.

The coverage of access controls are tradeoff between amount of the
changeset and valuable functionalities, in generally. Ultimately it
is a role of developer to decide what is unseparatable core feture
and what is separatable secondary one.

It is my decision to restrict types of database objects to reduce
burden of reviewers, so the latest one apply SELinux specific access
controls on only databases, schemas, tables and columns.

Even if we have a framework to host label-based MAC, its coverage shall
be unchanged, because comprehensive support at once obviously makes
harder to review.

>>> So with regard to confidence in the design I think that part of the
>>> reason for the skepticism in the fact that it was such a large code
>>> drop. Even the separated parts were very large.
>> Definitely true.
>>
>>> I think if the framework
>>> patches are broken up more logically and in a way that is easier to
>>> discuss then that might help the community get a grasp on what it is
>>> trying to accomplish.
>> Maybe, maybe not. Nobody's going to commit anything unless it's a
>> complete feature. It can be a cut-down feature, but it has to be of
>> independent use. If there are parts that can be peeled off of
>> SE-PostgreSQL and committed independently to some good benefit, then I
>> think that's a great idea. But if it's just a separation of the patch
>> for clarity, I don't think there's much value in that.
>
> I don't think it would be just for clarity. I know that not all open
> source communities are the same so I'll try to leave the anecdotal
> evidence light. When submit patches for the Linux Kernel we take a
> single feature and structure them as self contained logical changes.
> Separating the changes logically doesn't just improve clarity but also
> makes it easy to cherry pick features that can be useful on their own.
> Just because the framework and the SEPostgreSQL features would be two
> patch sets doesn't mean they aren't being developed in parallel. It
> looks to me that we're in the same boat we were in with SELinux. We had
> the feature and proposed it and someone brought up "well what about
> other security models". So time was spent developing a framework that
> everyone could use and as that was being done the SELinux patches were
> modified to use this new framework. They were two separate features
> developed in tandem. If we do it right the SEPostgreSQL code will be
> isolated from the framework and we can spend time putting the framework
> in and just plug in the specific security module when time comes. The
> X-ACE work went in to X before the corresponding SELinux Flask module
> for it and I don't believe LSM and SELinux went into the same merge
> window as well.

It is necessary to deploy the framework and SELinux support at same time
or the framework earlier than SELinux? We can organize a common framework
when the second security module will come in. From our experience, it may
need similar security hooks on same or similar strategic points.

In the development history, the code size and complexity had been a matter
for inclusion. I also think the idea to invoke security modules via mac
framework is right approach, but it increases the initial code size compared
to the current approach in spite of even user visible whorth.

>> I have proofread earlier versions of the docs and found them
>> inadequate. There were language issues, but the bigger problem was
>> that they were both too specific and yet not sufficiently detailed.
>> For example, they'd say "install X package on Red Hat". Well, what if
>> I'm not on Red Hat? The on the other hand they'd say "this GUC
>> enables mcstrans" which means nothing to me. I think this has been
>> improved somewhat in more recent version, but clearly we need (1) good
>> developer documentation, so someone other than KaiGai has a chance of
>> maintaining the code and keeping it correct as other things are
>> changed; (2) user documentation, so that someone can read the "feature
>> story" for this capability; and (3) reference documentation,
>> cross-referenced with the user documentation.
>>
>> Having said that, fixing the documentation won't get this patch
>> committed, though it's certainly a step in the right direction. For
>> that we need a committer-owner.
>>
>
> True but hopefully proper documentation will help someone decide that
> they have enough information to take on that position.

If you have any concern about documentations, I very welcome any feedbacks.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>