Re: Adding support for SE-Linux security

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.

> > 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.

>
> 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.

> ...Robert