Re: Adding support for SE-Linux security

On Fri, Dec 11, 2009 at 10:07 AM, David P. Quigley
<dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
> The main concern I hear is that people are worried that this is an
> SELinux specific design. I heard at the meeting on Wednesday that the
> Trusted Extensions people looked at the framework and said it meets
> their needs as well. If thats the case where does the concept that the
> design is SELinux specific stem from? We've asked Casey Schaufler the
> developer of another label based MAC system for Linux to look at the
> hooks as well and make a statement about their usability.

OK, on second thought I want to address this a little more, since some
of these concerns came from me. SE-Linux-specific may be the wrong
way to say it. There's an old saying that goes something like: if a
function has 10 parameters, it has 11 parameters. In other words, if
you're passing too much information across a supposed abstraction
boundary, it's not really an abstraction boundary at all.

If we design a security abstraction layer, the interfaces need to
really be abstraction boundaries. Passing the table OID and then also
the tablespace OID because PG DAC needs that to make its access
control decision is crap. As soon as some other security model comes
along you will need to add additional arguments for all of the things
that the new security model cares about, and when a third security
model comes along you will need to pass those things now too. If
we're doing that sort of thing, we might as well leave the entire
jumble of spaghetti code in its original location so that at least you
don't have to flip back and forth between two different source files.
And if we're going to do that, we might as well quit now because our
heads will explode (Tom's first).

I actually have an idea how to solve the problem in this particular
case, but I'm reluctant to say what it is because I'm not sure if I'm
right, and at any rate *I don't want to write this patch*. I may
review it and if it's good I may commit it (or more likely a more
extensive version of it after we have agreement on the basic
principles) but I don't to want to write it or do substantial cleanup
of it. I have my own list of things to work on and I presently have
no reason to put this on that list. As a community, I think that at
times we have a tendency to say "well, the committer is just going to
rewrite this anyway, so it doesn't really matter what we do". As far
as I am concerned that is flat false. I do not want to rewrite your
patch. I want to look at your patch, convince myself that it is
correct, and commit it. That won't always happen, and I'm certainly
willing to do more than that especially in cases where it's a feature
that I really care about, but AFAIAC the initiative is with the patch
author to provide something committable, NOT with the committer to fix
what the patch author did wrong. I realize that's subjective at
times, and I'm going to make my best effort not to be a jerk about it,
but given that there are only so many hours in the day (and not all of
the can be spent on PostgreSQL) I think that's the goal we need to
shoot for.

...Robert