Re: Adding support for SE-Linux security - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Adding support for SE-Linux security |
Date | |
Msg-id | 603c8f070912080848m2e33e4ct37e83350ebe5b5fe@mail.gmail.com Whole thread Raw |
In response to | Re: Adding support for SE-Linux security (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Adding support for SE-Linux security
("David P. Quigley" <dpquigl@tycho.nsa.gov>)
|
List | pgsql-hackers |
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
pgsql-hackers by date: