Re: Adding support for SE-Linux security - Mailing list pgsql-hackers

Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.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.

Basically, I don't think it is a bad idea to provide a framework to host
multiple label-based security mechanisms, because they have same origin
so they have similar features, such as security label and policy.

However, we have a tradeoff betweem an ideal image (multiple enhanced
security stuff can be launched via common hooks) and amount of changeset.
The latest SE-PgSQL/Lite patch support only four kind of database objects
(databases, schemas, tables and columns), so it puts security hooks on
the strategic points corresponding to these objects, such as createdb().

If we simply replace the invocations by the common hooks, coverage of the
framework will be restricted to these four objects. Is it possible to call
them as a framework?
If it will be comprehensive from the first, we shall face a nightmare again.

I think we can replace the sepgsql_*() invocations by the framework
when the second enhancement (such as Solaris-TX?) will come in.
Note that label-based security has historically same origin, so we
can expect much smaller arrangement than integration DAC and MAC.

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

Right, the default PG model has been already comprehensive, and has
a different origin from label-based securities, so we needed massive
changeset to organize both of DAC (the default PG model) and MAC into
a common security framework.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>