Re: Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)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(at)momjian(dot)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