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

On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl@tycho.nsa.gov> wrote:
> > On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
> >> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> > As Alvaro mentioned, the original patch used ACE but it added too much
> >> > code so the community requested its removal from the patch.  It could be
> >> > re-added if we have a need.
> >>
> >> Well, there's no point in putting that framework back in unless we can
> >> make it sufficiently general that it could be used to serve the needs
> >> of more than one security model.  And so far, the signs have not been
> >> promising.  David Quigley suggests downthread that making a truly
> >> general model isn't really possible, and he may be right, or not.  I
> >> was just mentioning that it's an angle I have been thinking about
> >> investigating, but it may be a dead end.
> >>
> >> The real issue is making the code committable, and then maintaining
> >> it, as Tom rightly says, forever.  We've got to make sure that we're
> >> willing to take that on before we do it, and I don't think it's a
> >> small task.  It isn't so much whether we want the feature as whether
> >> the level of effort is proportionate to the benefit.
> >>
> >> ...Robert
> >>
> >
> > So the issue with generality is that path name based MAC has a different
> > set of requirements than label based does. If you want to acomodate
> > several types of label based MAC models then a framework can be
> > developed for that similar to the one in the Linux Kernel. I asked
> > around after I sent the email yesterday and from what I understand
> > AppArmor does not have the concept of a userspace object manager so I
> > don't know what they'd do in this area. I'm sure they could come up with
> > a scheme to write policy for the database but I don't know how useful it
> > would be.
> >
> > If you look at the LSM framework in the Linux Kernel recently there have
> > been hooks added to accomodate path based MAC systems so it can be done
> > but adds another set of hooks. The important goal here though in
> > designing a framework is to make sure that you have a comprehensive list
> > of the objects you want to mediate and make sure you put the proper
> > enforcement points in. Someone may come along later and want to mediate
> > a new object or some new functionality may come along that introduces a
> > new object so a hook may then need to be added. Something to realize as
> > well is that a security model may not want to implement all of the hooks
> > and it doesn't have to. In the case of no module being loaded or someone
> > not wanting the loadable security module framework I'm sure we can
> > provide an option to reduce overhead or compile the framework out
> > completely.
> >
> > I'll take a look at his patches for the framework that KaiGai originally
> > proposed.
> 
> It sounds like the pathname-based schemes are not really designed to
> work inside of a database anyway, so my first thought is we shouldn't
> worry about them.  The label-based schemes are by their nature
> designed to apply in an arbitrary context being applied to arbitrary
> objects.
> 
> ...Robert


So I was reading through a set of slides that KaiGai has and he
mentioned a May commitfest link and I looked for the comments related to
his PGACE patches. I've been crawling through the commitfest paces so I
can figure out what the latest version of the pgace patch is. Does
anyone know when the patch was reduced to what it is today?

Dave