Re: Adding support for SE-Linux security

On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost wrote:
> * 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

I think what makes people think that the changes are SELinux specific is
that the examples given use SELinux contexts. I think it should be made
clear that saying that in the PG there is a database object and we want
to mediate access to create database objects is not SELinux or even MAC
model specific (asside from labels). However to say that a program
labeled myapp_t can connect to the database and create a table and when
its created its labeled mytable_t that would be something SELinux
specific. The framework idea separates that. It says hey here are the
objects in the system and here are the actions on them that we want to
mediate. I will admit that since SELinux is the driving MAC model for
the framework you're going to find that the objects and permissions are
the ones that it wants to control. However like Steven said, adding a
hook later on or having a model not use a hook is not a Herculean task.
We've proven time and time again with the LSM framework that when a
feature is added it is trivial to introduce a new hook to mediate it or
to place an existing hook. I understand that PostgreSQL is a fast moving
target with a large developer base but so is the Linux Kernel and a
similar framework has been working there for years now.

Dave