Re: Adding support for SE-Linux security

On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:

> 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(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
>
>
> 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
>
I'm another SELinux developer and I'd like to help out where I can here. I'm
a bit confused by this discussion of PGACE. I thought the postgresql
community agreed that they wanted this removed in order to make the patch
size smaller. Has that changed? Is the increase in patch size now
acceptable? Sorry if I'm joining the conversation late.

Thanks,
Chad Sellers