Re: Adding support for SE-Linux security

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> One of the major and fundamental stumbling blocks we've run into is
> that every solution we've looked at so far seems to involve adding
> SE-Linux-specific checks in many places in the code.

I've really got to take exception to this. I've only been following
along and not really participating because, to be honest, I'm frustrated
with how this has gone down. In the end there were at least two
patches, in my view, that *didn't* involve adding SE-Linux-specific
checks everywhere. The patch that I reviewed that got thrown out by
Tom, and the original PGACE framework. Both of those added alot of
*hooks*, because they were necessary, but nothing made those hooks
particularly "SELinux-specifc". We're hearing alot about things being
SELinux-specific from people who also profess to not know SELinux.

Indeed, as I recall, the patch I reviewed was primairly trying to just
addess pulling out the hooks necessary for the existing PostgreSQL
security model. Very little of it was SE-Linux specific *anything*.

I contend that while the specific hooks which would be added *in
places that don't already have checks* (in most places, the hook was
added to replace an existing check) are hooks that then make sense
for SELinux, they would also make sense for other frameworks. They
may also not be a complete list, but once the *framework* is in
place, adding new hooks (presuming another model would like a hook
somewhere that SELinux and the existing PG security framework don't)
should not require some kind of forklift upgrade.

> It would be nice
> if it were possible to use the exist permissions-checking functions
> and have them check a few more things while they're at it, but it's
> looking like that won't be feasible, or at least no one's come up with
> a plausible design yet.

The problem is that the existing permissions-checking is done all over
the place. That's not ideal from the get-go, in my opinion.
Unfortuantely, when we moved all of the permissions-checking to a single
place, it required knowing about alot of the backend, which Tom took
exception to. I agree that's frustrating, but I don't see it as a
particular reason to throw out the entire concept of a modular security
framework. Perhaps we need to better expose just those pieces the
security framework cares about from the other parts of the backend- it's
entirely likely that the reason it has to know about everything is that,
due to where all the existing security checks are, they just (ab)used
the fact that they had access to that information at hand for that
object type.

> Consequently there are checks spread
> throughout the code, which definitely complicates both validation and
> maintenance. One question I have is - are the places where those
> checks are placed specific to SE-Linux, or would they be applicable to
> any sort of label-based MAC?

The patch which I worked with Kaigai on was specifically geared to first
try to get a patch which addressed the existing PG security model in a
modular way, to allow additional hooks to be added later in places which
needed them, and to provide the information for other models to make a
decision about the permission. I don't feel it was particularly
SE-Linux specific at all, but rather a first step towards being able to
support something beyond the model we have today (anything..).

Thanks,

Stephen