Adding support for SE-Linux security
in [PgSql]
|
From: KaiGai Kohei on 9 Dec 2009 01:52 Stephen Frost wrote: > * Robert Haas (robertmhaas(a)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(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 9 Dec 2009 06:49 On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > 2009/12/9 Bruce Momjian <bruce(a)momjian.us>: >> I frankly think the patch should be thought of as the SE-Linux-specific >> directory files, which KaiGai can maintain, and the other parts, which I >> think I can handle. > > I think that's a horribly bad idea. Me, too. The ECPG comparison is apt, except that this code is far more deeply integrated into core. The idea that the SE-Linux directory files can be maintained separately from the "other parts" does not seem realistic to me. The problems that are going to occur here are things like: somebody wants to rearrange some part of the permissions checking for some reason. So they move a bunch of code around and break SE-PostgreSQL. Someone has to review that patch and understand the danger it causes. That's going to require understanding both the SE-PostgreSQL-specific files and the other parts, and the relationship between the two of them. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 9 Dec 2009 17:38 Robert Haas wrote: > On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote: > > 2009/12/9 Bruce Momjian <bruce(a)momjian.us>: > >> I frankly think the patch should be thought of as the SE-Linux-specific > >> directory files, which KaiGai can maintain, and the other parts, which I > >> think I can handle. > > > > I think that's a horribly bad idea. > > Me, too. The ECPG comparison is apt, except that this code is far > more deeply integrated into core. The idea that the SE-Linux > directory files can be maintained separately from the "other parts" > does not seem realistic to me. The problems that are going to occur > here are things like: somebody wants to rearrange some part of the > permissions checking for some reason. So they move a bunch of code > around and break SE-PostgreSQL. Someone has to review that patch and > understand the danger it causes. That's going to require > understanding both the SE-PostgreSQL-specific files and the other > parts, and the relationship between the two of them. We did something similar for Win32 because it was the only way to do it. We don't have the luxury of educating our developers on SE-Linux API for a while --- there is the ideal world, and there is reality. What this means is that SE-Linux would break when permissions changes happen, and the SE-Linux folks will have to come in and clean things up later. If you want to avoid all good reasons for this features and are looking for reasons why this patch is a bad idea, I am sure you can find them. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: KaiGai Kohei on 9 Dec 2009 19:28 Bruce Momjian wrote: > Robert Haas wrote: >> On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote: >>> 2009/12/9 Bruce Momjian <bruce(a)momjian.us>: >>>> I frankly think the patch should be thought of as the SE-Linux-specific >>>> directory files, which KaiGai can maintain, and the other parts, which I >>>> think I can handle. >>> I think that's a horribly bad idea. >> Me, too. The ECPG comparison is apt, except that this code is far >> more deeply integrated into core. The idea that the SE-Linux >> directory files can be maintained separately from the "other parts" >> does not seem realistic to me. The problems that are going to occur >> here are things like: somebody wants to rearrange some part of the >> permissions checking for some reason. So they move a bunch of code >> around and break SE-PostgreSQL. Someone has to review that patch and >> understand the danger it causes. That's going to require >> understanding both the SE-PostgreSQL-specific files and the other >> parts, and the relationship between the two of them. > > We did something similar for Win32 because it was the only way to do it. > We don't have the luxury of educating our developers on SE-Linux API for > a while --- there is the ideal world, and there is reality. What this > means is that SE-Linux would break when permissions changes happen, and > the SE-Linux folks will have to come in and clean things up later. > > If you want to avoid all good reasons for this features and are looking > for reasons why this patch is a bad idea, I am sure you can find them. > Right, I (and my employer) offers development and maintenance resource for the feature. If I'll be busy in future days, it means I'm devotedly working on this feature. When we need to change permission mechanism in the future, we can provide our efforts not to break them. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai(a)ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 9 Dec 2009 20:41
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian <bruce(a)momjian.us> wrote: > If you want to avoid all good reasons for this features and are looking > for reasons why this patch is a bad idea, I am sure you can find them. You seem to be suggesting that our reactions are pure obstructionism, or that they have an ulterior motive. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |